Ticc-paradigm to build verified parallel software for multi-core chips

ABSTRACT

This invention teaches a way of implementing formally verified massively parallel programs, which run efficiently in distributed and shared-memory multi-core chips. It allows programs to be developed from an initial abstract statement of interactions among parallel software components, called cells, and progressively refine them to their final implementation. At each stage of refinement a formal description of patterns of events in computations is derived automatically from implementations. This formal description is used for two purposes: One is to prove correctness, timings, progress, mutual exclusion, and freedom from deadlocks/livelocks, etc. The second is to automatically incorporate into each application a Self-Monitoring System (SMS) that constantly monitors the application in parallel, with no interference with its timings, to identify and report errors in performance, pending errors, and patterns of critical behavior. This invention also teaches a way of organizing shared-memory for multi-processors that minimizes memory interference, protects data and increases execution efficiency.

GLOSSERY: ABBREVIATIONS IN ALPHABETICAL ORDER

-   ALLEOPs: ALLowed Event Occurrence Patterns-   CCP: Casual Communication Primitive-   CCS: Calculus for Communicating Systems-   CIP: Cell Interaction Protocol-   CPU: ComPuting Unit, hardware-   CSP: Communicating Sequential Processes-   CTL: Casual Temporal Logic-   dm-pathways: distributed memory communication pathways-   ECT: Event Characterization Table-   FSP: Finite-State Processes-   ndFSP: Non-deterministic FSP-   NFSP: Non-FSP-   OO: Object Oriented-   sm-pathways: shared memory communication pathways-   SMS: Self-Monitoring System-   TICC™: Technology for Integrated Computation and Communication-   TICC™-Ppde: TICC™-based Parallel Program Development & Execution    platform-   TICCNET™: TICC™-based local area communication NET-   TIP: Thread Interaction Protocol

BACKGROUND OF INVENTION

This invention teaches how TICC (Technology for Integrated Computationand Communication, U.S. Pat. No. 7,210,145 B2, Apr. 24, 2007, Inventor:Chitoor V. Srinivasan) is used to build formally verified massivelyparallel software systems that run in arbitrarily large numbers ofShared-Memory Multi-core Chips (SMMC) or any collection of Shared-Memorymulti-Processors (SMPs) interconnected by the local area net, TICCNET™(TICC™-based local area communication NET), and run at 90%-100%efficiencies. The organization and operation provides (i) an idealenvironment for designing, implementing and formally verifying parallelsoftware systems; (ii) starting from an abstract specification ofinteractions among parallel software computing units called cells andprogressively refining the implementation to its final form; (iii)providing the right programming abstractions and tools for developingmassively parallel software applications in a diversity of SMMC networkswith guaranteed data and system security; (iv) automatically generatingat each stage of implementation a formal event based model of definedcomputations, called ALLowed Event Occurrence Patterns (ALLEOPs), which(v) is used not only to formally verify properties of definedcomputations such as correctness, timings, synchronization,coordination, progress, liveness and freedom from deadlocks, stated in aCausal Temporal Logic language (CTL-language), but also to (vi)automatically implement a Self-Monitoring System (SMS), which monitorsthe performance of the implemented application through out its lifetime, in parallel with its operations, with no interference with itstimings, in order to identify and report errors in performance,impending errors and occurrences of alert situations defined a priori.

TICC™-Ppde is the software platform for developing and executingTICC™-based parallel programs. It has the potential to transform allfuture application software to fully verified parallel software systems,running in a diversity of desk-top and lap-top computers with multi-corechips, thereby providing easy access to enormous computing power,security and data protection not realizable in the technology we usetoday.

TICC™-Ppde adapts and integrates modified versions of seven otherprogramming paradigms: (i) the OO (Object Oriented) paradigm [Martin 1,Alan 2, Armstrong 3, Bertrand 4], (ii) parallel computations as inActors [Hewitt, 5] [Agha, 6][Clinger, 37], (iii) interactionspecifications as in π-calculus [Milner, 7,8,9] (iv) integration ofcomputation and communication as in CSP (Communicating SequentialProcess) [Hoare, 10,11,12], (v) verification of implementations similarto design verification through FSPs (Finite State Processes) [Magee &Kramer, 13], (vi) verification of NFSP (Non-FSP) systems similar to[Hoare, 15] and [Manna, 16.17,18], and (vii) communication usingmodified RESTCLK-pathways [Das, 19]. Communication mechanisms, parallelprogram organization and proof methods used in TICC™-Ppde are new.

Integration of these paradigms is made possible by the use of a variantof TICC™, which enables hardware and software computing components toexchange signals programmatically. All communications, parallel processand pthread (parallel thread) interactions, security enforcement,interrupt handling, synchronization, coordination and self-monitoringare driven by programmatic signal exchanges without need to use anOperating System (OS), while preserving mutual isolation of all softwareand hardware components. Cells, operate in parallel and not in timesliced¹ concurrency as in FSP [Maggie & Kramer, 13] and CCS (Calculusfor Communicating Systems) [Milner, 14]. Each cell operates in its ownassigned hardware CPU and no other cell uses that CPU unless the cell,to which the CPU has been assigned, suspends or terminates itsoperations and releases that CPU. TICC™-Ppde based parallel processingrequires and can accommodate large numbers of CPUs. Besides simplifyingparallel programming and providing methods for formal verification anddynamic self-monitoring, TICC™-Ppde offers several other benefits,outlined in the SUMMARY section. ¹ We use the phrase “time-sliced” torefer to concurrent executions where events may not occursimultaneously, but only in mutually exclusive time slices. Such systemsare usually scheduled and driven by a monitor in an operating system.

Chapter 2 presents a summary. Chapter 3, presents the following througha series of examples: (i) Principles of organization; (ii) Nature ofcommunication and computation; (iii) Models of computations as definedby ALLEOPs, which are automatically derived from implementations; (iv)Verification of implementations using evaluations of givenCTL-assertions (Causal Temporal Logic assertions) over ECT-networks(Event Characterization Table networks), which are automatically derivedfrom ALLEOPs; (v) synchronization, coordination, data protection,security enforcement and self-monitoring; and (vi) special facilitiesneeded in TICC™-CPU to efficiently execute parallel programs based onthe TICC™-Paradigm in SMMCs (Shared-memory Multi-Processor MulticoreChips) with enhanced data and system security, while simplifying CPUdesigns.

TICCNET™ is a TICC™ based distributed-memory hardware communicationnetwork that may be used for group-to-group high-speed message exchangesamong SMMCs (Shared-memory Multi-Processor Multicore Chips) and/or SMPs(Shared-memory Multi-Processors) in a local area supercomputing gridcontaining as many as 256 or more SMMCs and/or SMPs, each SMMC or SMPwith 32 or 64 processors or more. We envision multi-core chips in thenear future with multiple SMMCs integrated in a single chip. TICCNET™may be integrated in such SMMCs chips for high-speed group-to-groupdistributed-memory communication among the SMPs in the chip. However, ifthe TICC™-based shared-memory organization described in Chapter 3,Section 8.2 is used, it is not necessary to integrate TICCNET™ in SMMCchips.

SUMMARY OF INVENTION

(1). Implementation through Successive Refinements: TICC™-Paradigmintroduces a method to develop formally verified applicationimplementations through successive refinements starting from abstractspecifications of interactions among a set of parallel softwarecomputing units, called cells. Cells perform parallel computations byexchanging messages among themselves through communication pathwaysconnected to ports attached to the cells. A message subclass, method,pthread or condition is abstract, if only its name, and names ofarguments if any, are specified together with contexts in which they areinvoked and executed in an implementation, but computer programs thatimplement them are not defined yet. A compound cell if the sub-networkof other cells and pathways that it encapsulates is undefined or arethemselves abstract. An example of such a compound cell, called Person,encapsulating its enclosed sub-network is shown in FIG. 7. A design,Ap:design(), for an application Ap specifies (i) cells, ports attachedto cells, pathways interconnecting the ports, (ii) abstractspecifications of interactions among the ports called Thread InteractionProtocols (TIPs), and (iii) abstract specifications of processes run bycells, called Cell Interaction Protocols (CIPs). Subclasses of messagesexchanged by cells via their ports, their synchronization andcoordination are implicit in Ap:design().

Refinements involve definitions of computer programs that defineabstract methods, pthreads (parallel threads) and conditions in a givenabstract design of an application, and definitions of messagesubclasses. They also involve decomposition of compound cells to definethe sub-networks that they encapsulate. Refinements are performed in agoal directed manner following flow of messages among cells inAp:design(). Ap:implementation() is fully refined and complete, ifcomputer programs have been defined for all abstract methods, pthreadsand conditions in Ap:design() and all needed message subclasses havebeen fully refined.

Developing Ap:design() focuses only on system decomposition andinteractions between components in the system. No programming issues areinvolved here; programming beings on IV after Ap:design() has beencompleted. While developing Ap:design(), Ap:requirements() are alsodeveloped. Ap:requirements() is a set of assertions stated in a CausalTemporal Language, CTL-assertions, which the implemented system shouldsatisfy. CTL-assertions are defined in Section 5, Chapter 3 withexamples appearing throughout Chapter 3.

As Ap:implementation() evolves, during the refinement process,Ap:requirements() are also refined, modified and updated. At each stageof refinement, TICC™-Ppde automatically derives ALLEOPs, traces andECT-Tables (these are defined below) from given specifications, and usesthese to automatically verify assertions in Ap:requirements(), at everystage of the partially refined Ap:implementation(), wherever feasible.For each method, condition and pthread defined during the refinementprocess, the programs developed for them are formally verified toascertain that they satisfy requirements in Ap:requirements(). WhenAp:implementation() is completed additional CTL-assertions needed toverify the implementation, as per (6.44) in Chapter 3, are provided bythe implementers and designers. System development is considered to becompleted only when validity of (6.44) has been formally verified.Throughout an implementation process, program development andverification proceed concurrently.

(2). Event Classes: There are two kinds of event classes: communicationevent classes and action event classes. Roughly speaking (more detailsin Chapter 3, Sections 2 and 5), communication event class is a pair,(p^(S),T(p^(S))), (p^(F),T(p^(F))) or (p^(D),T(p^(D))) where p is a portthat sends (superscript S), forwards (superscript F) or delivers(superscript D) a message via a pathway. T( . . . ), is the time-mapassociated with the event class. The time-map T(X) for a communicationevent x stands for a sequence of time points at which instances of theevent class x may occur in a run of an application. An action eventclass is a pair, (name,T(name)), where name is the name of a variable,condition or action and T(name) is the time-map representing sequencesof time-points at which the named variable is accessed and/or set, orthe named condition becomes true or the named action is executed.Whereas instances of action events may change the world states of cellsthat execute the actions in parallel computations, instances ofcommunication events will change only the states of components incommunication pathways.

(3). ALLEOPs: ALLEOPs (ALLowed Event Occurrence Patterns) of anapplication specifies patterns of events that may occur while theapplication is running. The pattern is specified by a directed graphwhose nodes are event classes and whose directed arcs are causalrelations. They are described in Chapter 3, Section 2. Eachimplementation will have a unique ALLEOPs graph associated with it. TheALLEOPs graph for an implementation of an application is automaticallyderived by TICC™-Ppde from implementation specifications.

(4). Causality: We write x(t₁) to refer to an event instance, of theevent class (X,T(X)), occurring at time t₁. If x(t₁) occurs in a run ofan application then t₁εT(X). Hereafter, we will simply write x forreferring to the event class (X,T(X)), unless there is a need to specifythe time-map T(X). We write, (X→Y), if (X causes Y) holds true inALLEOPs in the sense, occurrence of an instance of X causes theoccurrence of an instance of Y. We write C(X,Y)?(){X→Y} if (X causes Y)only if an instance of X has already occurred and instance of Y occursonly if condition C (X,Y) true at the time of occurrence of instance ofY. Causality is an irreflexive transitive asymmetric relation meaning,(X→X) is impossible (irreflexive), (X→Y) & (Y→X) is also impossible(asymmetric), (X→Y→Z) implies (X→Z) (transitive), and[C₁(X,Y)?(){X→Y}→C₂(Y,Z)?(){Y→Z}] implies [C₁(X,Y)?() &C₂(Y,Z)?(){X→Y→Z)] (transitive). A causal chain is a concatenation ofarbitrary number of successive causal relations, as in (X→Y→Z→ . . . )the causations in the causal chains appearing with or withoutconditions. Causal relations are interpreted as described below.

(5). Causality Interpretation: If in a run of an application, aninstance x(t₁) of (X,T(X)) causes the instance y(t₂) of (Y,T(Y)) tooccur then we write it as (x(t₁)→y(t₂)). In this case, of course,t₁εT(X) and t₂εT(Y) would hold true. If (x(t₁)→y(t₂)) is true in a runof an application, then either (i) (X→Y) should occur in the ALLEOPs ofthat application and (t₂−t₁)≦τ_(max)(X,Y) where τ_(max)(X,Y) is themaximum delay that can occur between occurrences of instances x and y,or (ii) [C(X,Y)?(){X→Y} occurs in the ALLEOPs and

C(X,Y)

(t₂) & (t₂−t₁)≦τ_(max)(X,Y))], where

C(X,Y)

(t₂) asserts, condition C(X,Y) is true at time t₂. Implementers estimatethe maxima τ_(max)(X,Y) at the time of implementation, and confirm themafter experimenting with a completed implementation.

(6). Causalnet: Causalnet of an application is the set of all causalchains of communication event instances that occurred in a run of thatapplication. All action events are ignored and only communication eventsappear in causalnets. An application operates correctly (Chapter 3,Section 6.5) if only if Condition-1 below holds true in every causalnetof the application:

∀(X)∀(t ₁)∀(Y)∀(t ₂)[(x(t ₁)→y(t ₂))

[(((X→Y)

(C(X,Y)?(){X→Y} &

C(X,Y)

(t ₂))) & (t ₂ −t ₁≦τ_(max() X,Y)))]  Condition-1

This condition asserts, Causality Interpretation should hold true forall communication event instances that occur during any run of anapplication. Timing here is a property of events used to modelcomputations, not a parameter of computations. Causalnets are graphswhose nodes are event instances and whose directed arcs are causal linksconnecting pairs of nodes in the graphs. Causalnet associated with a runof an application, is automatically generated by the SMS(Self-Monitoring System) while the application is running, in parallelwith the application.

SMS uses specialized cells called Event-Builder cells, eb cells to buildcausalnets. It uses specialized Event-Analyzer cells, ea cells, toanalyze the growing causalnet to check whether condition-1 holds true inthe causalnet and issue reports when condition-1 is violated, or modifyapplication behavior based on recognized event patterns in thecausalnet.

Every computational step has one or more events associated with it.Occurrence of one event may cause other events to occur. All eventsoccur at discrete points of real time. During proof construction thetime points are postulated for events in a manner that is consistentwith the time-maps specified in ALLEOPs. Ability to predict timings forany pair of events X and Y with in given tight bounds τ_(max)(X,Y) inCondition-1, is a consequence of TICC™-Ppde execution characteristics(Chapter 3, Section 4.6) and elimination of speed-up techniques referredto in Feature 4 below. Event occurrence patterns in causalnets, causalchains, conditions associated with them, event timings and states ofcomputing units (cells) are all used in proof construction.

(7). FSP, NFSP and CTL-Assertions: ALLEOPs model both FSP (Finite StateProcess) and NFSP (Non-Finite State Process) systems. Unlike FSP modelsused in Maggie & Kramer [13], ALLEOPs are not models of intended systemdesigns, but they are models of actual implementations, derivedautomatically from implementation specifications at various stages ofrefinements. Traces are derived automatically from ALLEOPs and ECTs(Event Characterization Tables) are derived, again automatically, fromtraces. ECT-networks represent information in traces in a tabular formthat is convenient for ALLEOP-proof construction. Interactive proofs ofproperties of implementations, stated as CTL-assertions (Causal TemporalLogic assertions) are developed through symbolic evaluation ofCTL-assertions over ECT-networks. CTL-assertions are similar toassertions used in Clark [38-40] Emerson, [41] and Sifakis, [42]; theyare also similar in certain ways to the FSP language used in [Magee &Kramer, 13]. But, there are differences, which may be noted in theexamples presented in Chapter 3. The particular syntax used for CTLassertions is not important, as long as it has a commonly acceptedunambiguous interpretation [38-42].

(8). Proofs: Proofs do not require an inference engine forCTL-assertions, proofs require only a method to evaluate CTL-assertionsover ECT-networks. However, proofs do require an inference engine forpropositional expressions. Evaluation of CTL expressions overECT-networks provides the contexts for propositional inferences neededin a proof. Users specify implementations, CTL-assertions to be proven,and provide definitions, axioms and other CTL-assertions that may bepertinent to the proofs. Proof methods are illustrated in Section 6 ofChapter 3. A finite-ALLEOP is one that has an equivalent FSP model. Agiven ALLEOP may have both FSP and NFSP properties; proofs of the latterare necessarily more complicated.

(9). Dynamic Self Monitoring, SMS: SMS (Self-Monitoring System) is anintrinsic built-in part of TICC™-Ppde program execution mechanism. Thus,once a TICC™-Ppde implementation of an application, Ap, is completed,self-monitoring is automatic. Implementers do not have to specify anypart of SMS. SMS dynamically generates the causalnet for the applicationAp while it is running, in parallel with the running of Ap, with littleor no degradation of execution efficiency and timings in Ap, during thelife time of Ap. The causalnet of Ap is the network of all (and only)communication event chains that occur during the run of Ap. An error isreported by ea-cells whenever Condition-1 is violated; an impendingerror is reported if only the specified upper bound τ_(max)(X,Y) inCondition-1 is violated for some event classes X and Y in the ALLEOPs.One may define patterns of critical behaviors in a regular grammar usingALLEOP nodes as terminal symbols, and have the ea-cells issue an alertor modify system behavior whenever any of the defined patterns occur inthe causalnet. SMS provides the infrastructure for developingself-diagnosis, self-repair and learning capabilities.

(10). High-speed Parallel Communications: As explained in U.S. Pat. No.7,210,145 B2, dated Apr. 24, 2007, TICC™ adapts RESTCLK [Das, 19]communication paradigm. Communication in TICC™ is connection oriented:Two cells may communicate with each other if only if they have portsthat are connected to each other by communication pathways. Theadaptation of RESTCLK to TICC™-Ppde changes the protocols used forexchanging signals between components in a pathway and changes themanner in which protocols are evaluated. Adaptation of TICC™ toTICC™-Ppde modifies the structure of pathways. Pathways in TICC™-Ppdeincorporate SMS mechanisms; pathways in TICC™ do not. TICC™-Ppde alsochanges the manner in which protocols associated with the pathways areexecuted. Communications in TICC™-Ppde may occur both in shared-memoryand distributed-memory environments. Communications in TICC™ and RESTCLKmay occur only in shared-memory environments. The adaptationsincorporated into TICC™-Ppde, also enable parallel simultaneousinstantaneous asynchronous communications with guaranteed high-speedmessage deliveries with a priori known bounded latencies in hundreds ofnanoseconds range, using 2 gigahertz/sec CPUs. Differences betweenTICC™-Ppde and TICC™, and TICC™-Ppde and RESTCLK, are discussed laterbelow, after presenting the common features in all the three.

Common Features of TICC™ RESTCLK and TICC™-Ppde: Each port may beattached to only one cell called the parent-cell of the port (preventsport contention), and each port may be connected only to one pathway(prevents message interference). There are three kinds of ports, allsoftware components: generalPorts used to send out service requestmessages; functionPorts used to receive and respond to service requestmessages, and interruptPorts used to receive interrupt messages andrespond to them. Every cell should have at least one of each kind ofport. Similar pathway structures are used in all the three, TICC™-Ppde,TICC and RESTCLK.

Differences between TICC™ RESTCLK and TICC™-Ppde: Differences appearonly in message exchange mechanisms and methods used to executecommunication protocols. They are described below.

Message Exchanges in TICC™: TICC™, described in patent, U.S. Pat. No.7,210,145 B2, scheduled and implemented message exchanges usingspecialized cells called communication processors, which operated inparallel with other cells in an application, Ap. Each cell in Ap sentrequests to transmit messages to a communication processor of Ap. Thecommunication processor transmitted messages by executing protocolsassociated with the pathways specified in the requests. Protocols wereexecuted in the order requests were received. Thus, even though it tookonly a few hundred nano-seconds to deliver a message in shared-memoryenvironments, using a 2-gigahertz CPU with 1 gigabits/sec memory bus,latency for delivering a message could be as large as 6 to 10microseconds, because a request for sending a message might have to waitin a queue for its turn to be serviced by a communication processor. Thenumber of messages that may be simultaneously sent in parallel in TICC™is limited to the number of distinct communication processors in anapplication. Thus, message delivery times are unpredictable in TICC™,but no message is ever lost and messages are delivered in the orderrequests were received by the communication processors.

Message Exchange in RESTCLK: In RESTCLK signal exchanges betweencomponents in a pathway are specified by small threads. Execution of thethreads caused signals to be processed and exchanged between componentsembedded in pathways. These threads were executed in a time-slicedconcurrent execution environment, where triggering of thread executionswas controlled by an Operating System monitor. Message deliveriesoccurred whenever execution of all signal exchange threads associatedwith a pathway were completed in an appropriate order. Time-slicedexecution regimen caused execution of signal exchange threads belongingto different pathways to be interleaved with each other. Thus, afterexecuting a thread corresponding to a signal exchange in one pathway, P,the monitor might cause threads in one or more other pathways to beexecuted, before resuming execution of the next signal exchange threadin P. This made message delivery times unpredictable. Messages could notbe delivered in the same order they were sent. Also, unfortunately,messages were sometimes lost. There is no concept of parallelsimultaneous message deliveries in RESTCLK.

Both TICC™ and RESTCLK do not support communications in distributedmemory environments. They require use of local area nets such asEthernet [Spurgeon, 22] or Myrinet [Myrinet, 28] for distributedcommunications.

Message Exchange in TICC™-Ppde: TICC™ and RESTCLK message exchangemechanisms should be contrasted with simultaneous parallel messageexchange mechanisms in TICC™-Ppde outlined below, where communicationprocessors are not used, and time-sliced concurrent execution is notused either. Each cell C_(i) sends message via a pathway,C_(i).p.pathway, connected to one of its ports, C_(i).p, by evaluatingthe message exchange protocol C_(i).p.pathway.protocol=C_(i).p.protocolthat is associated with that pathway and port, using the CPU, C_(i).cputhat has been assigned to C_(i). Once a protocol execution begins, itcan never be interrupted, until message delivery to intended recipientports, C_(j).q, for j>1, also connected to C_(i).p.pathway, C_(i)≠C_(j),has been completed. No C_(j).q may attempt to send a message whileC_(i).p is sending one. Uninterrupted protocol execution, immediatelyafter a message becomes ready to be sent, cause high-speed instantaneouscommunications in TICC™-Ppde both in shared-memory anddistributed-memory environments with predictable latencies. Distinctcells with ports connected to distinct pathways may exchange messages inparallel simultaneously. The number of messages that may besimultaneously sent in parallel is limited only by the total number ofdistinct cells and pathways in an application. Messages sent by any onecell are always delivered in the order they are sent. No message is everlost. TICC™-Ppde supports communication in a distributed memoryenvironment using TICCNET™, which is integrated with computationsperformed by cells. Distinctive characteristics of communications inTICC™-Ppde are itemized below.

(11). CCPs & Protocols in TICC-Ppde: Each CCP (Causal CommunicationPrimitive) has the form X: z→Y where X and Y are components embedded ina pathway and z is a one or two bit signal. All protocols are defined byconcatenations of CCPs; the concatenations having the form X:z₁→Y:z₂→Zwhere X, Y and z are all components in the same pathway, and z₁ and z₂are signals. Sequences of concatenated CCPs may appear embedded in otherprogramming language statements in a protocol (Section 7). When aprotocol is executed, it causes components in the pathway associatedwith the protocol to exchange signals among them, and respond toreceived signals. Signals exchanged by pathway components travel overthe pathway and eventually establish the context for message delivery tointended recipient ports or message transmission to them.

Operation of each CCP is defined by an ndFSM (non-deterministic FiniteState Machine) embedded in pathway components, as explained in Section 1of Chapter 3. It takes about 25 to 50 nanoseconds to execute a CCPimplemented in software in a 2 gigahertz CPU (hardware ComPuting Unit)with 100 mega-bits/sec memory bus. CCP may also be implemented as ahardware machine instruction in a CPU. If implemented as a machineinstruction, CCP execution will take no more than 5 nanoseconds in a2-gigahertz CPU.

(12). Pathways and VirtualMemories: Each port, C.p, of a cell, C, isconnected to a unique pathway, C.p.pathway. No port may have more thanone pathway connected to it. This prevents message interference duringparallel message transfers. Each pathway is defined by a network ndFSMs.The ndFSMs in the pathway are interconnected by branches, and eventuallyconnected to ports in that pathway also by branches.

There are two kinds of pathways, sm-pathways (shared-memory pathways)and dm-pathways (distributed-memory pathways). Branches and all othercomponents, such as ports, agents and virtualMemories, in sm-pathwaysare software components and branches in dm-pathways are hardware signaltransmission lines. Dm-pathways also contain other components such asports, agents, switches and routers. Dm-pathway ports are softwaredevice. Others are hardware devices. The term pathway refers to eitherone of them, sm-pathway or dm-pathway.

Only pathways that deliver messages have virtualMemories associated withthem. VirtualMemories hold messages that are exchanged and also holdmethods and pthreads (parallel threads) that process and build messages.VirtualMemories are declared for pathways at the time pathways areinstalled. Real memories are allocated to virtualMemories either atcompile time or run time. Pathways that do not deliver messages, butonly deliver signals, are called simple pathways. They do not havevirtualMemories. All pathways likely to be used in parallel programs arepredefined and provided to application programmers by TICC™-Ppde.Application programmers have to only install predefined pathways atappropriate places in the application that is being implemented.

The virtualMemory, if any, associated with the sm-pathway C.p.pathway iscalled C.p.vM. The virtualMemory C.p.vM, if it exists, is always unique.If C.p.pathway is a dm-pathway then each port, q, connected to thatC.p.pathway (C.p being one of those ports q) will have a distinctvirtualMemory, q.vM, associated with it. These distinct virtualMemorieswill reside in distinct SMPs (Shared-Memory multi-Processors), which areinterconnected by the dm-pathways in a TICCNET™. No two distinctpathways share any virtualMemory in common.

FIG. 24 shows a schematic diagram of a dm-pathway, and FIGS. 1 through 4and 19 show schematic diagrams of sm-pathways. We refer to sm-pathwayswith virtualMemories as Das-pathways, since they were first introducedby Das [Das, 19].

(13). Pathways and Protocols: Each port C_(i).p has a distinct protocol,C_(i).p.protocol=C_(i).p.pathway.protocol that is associated with it.Only the parent-cell C_(i) of the port C_(i).p may evaluateC_(i).p.protocol. Each C_(i) evaluates C_(i).p.protocol in order totransmit signals over C_(i).p.pathway and deliver a message.

It is possible that a group of ports, G₁=[C₁.p, C₂.p, . . . , C_(n).p]send a joint message to another group of ports, G₂=[C_(j).q, C₂.q, . . ., C_(m).q], C_(i)≠C_(j) for 1≦i≦n and 1≦j≦m, through a pathway, P. Sucha pathway is shown in FIG. 19. In this case the joint message is held ina virtualMemory M=G₁.vM=G₂.vM common to all ports connected to pathwayP. Every cell C₁ for 1≦i≦n executes C_(i).p.protocol in parallel withother cells as soon as it completes its contribution to the jointmessage, in order to deliver that message to ports in G₂. Agents in thepathway coordinate signal transmissions over the pathway P, caused bythese parallel protocol executions and guarantee that message in thevirtualMemory M is delivered simultaneously, in parallel, to all therecipient ports in G₂, only after all cells C₁ for 1≦i≦n have completedtheir respective contributions to the joint message. While cells C₁ for1≦i≦n are sending a message, cells C_(j) for 1≦j≦m cannot send anymessage.

If P is a dm-pathway, then signals traveling over the pathway establisha context in which message in M is simultaneously transmitted tovirtualMemories q.vM of all recipient ports q being connected to P viahardware transmission lines. In this case agents embedded in Pcoordinate parallel signal and message transmissions over thedm-pathway, and P.protocol specifies how this coordination is done usingCCPs.

(14). TICCNET™: TICCNET™ is the communication network containing alldm-pathways. The number of distinct dm-pathways in TICCNET™ may be inthe thousands. The number of messages that may be transmitted inparallel over a TICCNET™ is limited only by the number of distinctdm-pathways in that net.

(15). Elimination of Scheduling Delays: To send a message via a portC.p, the cell c first writes the message to be sent in the virtualMemoryC.p.vM in C.p.pathway. Immediately after writing the message the cell cexecutes eval(C.p.protocol), which evaluates C.p.protocol causingsignals to travel along C.p.pathway. C.p.pathway could be a sm-pathwayor a dm-pathway. The message writing and protocol execution areperformed by the same cell, one following immediately after the other,no matter what kind of pathway is connected to port C.p. This eliminatesscheduling delays. Pathways without virtualMemories will deliver ortransport only signals to intended recipients and no messages.

While executing a protocol, cell does not use any method not defined inthe protocol itself; neither will the cell invoke any process that isexternal to the cell. As mentioned earlier, protocols consist ofsequences of CCPs concatenated with each other, possibly embedded inother statements in a programming language and each CCP may be compiledinto a machine instruction. Thus, there is no difference betweencomputations performed by a cell to create and write a message into avirtualMemory and computations performed by the same cell to dispatchand deliver message/signal to its intended recipients, except in thedetails of computer programs defining those computations, Bothcomputations are strictly private to that cell and totally independentof whatever might be happening in other cells.

(16). Elimination of Synchronization Delays: Synchronization delays areeliminated by keeping hardware and software components of each pathwaythat exchange signals always tuned to each other. Each such tunedcomponent will be always ready to receive and respond immediately tosignals sent by other components in that pathway, no matter howcomplicated the pathway is. This kind of tuning is accomplished usingmethods described in Section 1 of Chapter 3. Tuning totally eliminatessynchronization delays during signal exchanges.

(17). Elimination of Sequential Buffering in AsynchronousCommunications: Any cell may send out and deliver a message/signal atany time it is ready to do so without any synchronization, coordinationor scheduling delays. Neither message-sending nor the message-receivingcells are blocked during such communications. All message/signalexchanges are asynchronous. As explained in Chapter 3, no sequentialbuffering is ever used to support such asynchronous message/signalexchanges; instead a parallel buffering mechanism is used, usingvirtualMemories of pathways.

(18). Parallel Simultaneous Message Exchanges: It is always true thatdistinct cells may simultaneously execute only distinct protocolsassociated with distinct pathways connected to distinct ports. This isbecause, (a) each cell may execute protocols associated only with theports attached to it and each port has a distinct pathway and protocolassociated with it. (b) Each cell may execute only one protocol at anytime. (c) Each port may be attached to only one unique cell, (d) Nopathway may ever transmit messages between two ports attached to thesame cell. (e) Parent-cells of message-sending and message-receivingports connected to a pathway cannot both simultaneously execute theprotocol associated with that pathway at any time, (f) When more thanone message-sending port in a port-group, [C₁.p, C₂.p, . . . , C_(n).p],belonging to distinct cells, C_(i) for 1≦i≦n, is connected to a pathway,P, each port C_(i).p in the port-group will have a distinct protocol,C₁.p.protocol, associated with it, each C₁.p.protocol pertaining totransportation of messages through the pathway P. (g) In this case, asmentioned earlier, simultaneous parallel execution of C₁.p.protocol byparent-cells C₁ for 1≦i≦n, is automatically coordinated by agentsembedded in P. (h) Execution of the protocol of a pathway (sm-pathway ordm-pathway) may change only the states of components in that pathway andnothing else. (h) No two pathways (sm-pathways or dm-pathways) share anycomponent in common. (j) Finally, each cell runs in its own assigned CPUthat is not shared with any other cell. These features togetherguarantee, simultaneous parallel execution of protocols by distinctcells without mutual interference, thereby enabling parallel messagetransfers in both sm-pathways and dm-pathways, the number of suchparallel simultaneous message transfers being limited only by the numberof distinct pathways in an application, which could easily run into tensof thousands.

(19). Guaranteed High Speed Parallel Communications: The following fourfeatures of communications in TICC™-Ppde guarantee high-speed parallelmessage exchanges with latencies in the range of a few hundrednanoseconds or less: (a) All synchronization and scheduling delays aretotally eliminated; (b) no protocol execution may ever be interrupted byany process; (c) multiple messages may be exchanged in parallel viadistinct pathways; (d) no sequential buffers are used in asynchronouscommunications. Even though pathways contain mechanisms forself-monitoring, they do no affect high-speed message transmissions.These are the principal differences in communications between TICC™-Ppdeand communications in TICC™ and RESTCLK.

If CCP is implemented in hardware as a machine instruction in2-gigahertz computing units with 1-gigabits/sec memory bus,point-to-point messages may be exchanged via sm-pathways with in tens ofnanoseconds. Group-to-group message exchanges from one group of ports toanother group of ports via sm-pathways may take a few hundrednanoseconds depending on the number of ports in each port-group.Group-to-group messages/signals may be exchanged via dm-pathways in lessthan 500 nanoseconds (estimated) plus signal transmission time. Indm-pathways, the message sending port-group in one SMP alwayssynchronously delivers messages/signals to one or more message receivingport-groups in other SMPs, as shown in the diagram in FIG. 24. Thenumber of parallel message/signal transfers that may simultaneouslyoccur in an application at any given time is limited only by the numberof distinct dm-pathways in the TICCNET™ of the application, which mayrun into thousands, plus the number of distinct sm-pathways inshared-memory environments of that application, which may run into tensof thousands.

Thus, unlike RESTCLK [Das, 19] and TICC™, TICC™-Ppde pathways enablehigh-speed simultaneous parallel message/signal exchanges among cells,with guaranteed message delivery and bounded latencies of the order ofhundreds of nanoseconds both in shared-memory and distributed-memoryenvironments of massively parallel software applications. Also unlikeRESTCLK [Das, 19] and TICC™ TICC™-Ppde pathways incorporate mechanismsfor the SMS embedded in them (Item (20) below and Section 7).

(20). Self-Coordination, Self-synchronization and Self-Monitoring: Eachgroup-to-group sm-pathway connects a group of generalPorts to a group offunctionPorts (FIG. 19). No two ports in a port-group may belong to thesame cell. Let us consider the group-to-group sm-pathway illustrated inFIG. 19. It contains one virtualMemory, M, which has four agents, a0,a1, a2 and a3, attached to it. Agent a0 is connected to ports in themessage-sending generalPort group, G, and a1 is connected to ports inthe message-receiving functionPort group F. Agents a0 and a1 are also,respectively connected to agents a2 and a3, which in turn are connectedto ports eb.f₁ and eb.f₂ of the cell eb (see FIG. 19). The cell eb isthe Event Builder cell that participates in building the causalnet,mentioned earlier. Functions performed by the eb cells are described inChapter 3, Section 7. It is possible that a group-to-group pathwaydelivers a message sent by a port-group back to the same port-group asshown in FIG. 17. Such pathways are called self-loop pathways,

Parent-cells of ports in port-groups are called cell-groups.Parent-cells of a generalPort group, G, send a joint service requestmessage to the functionPort group, F, via the pathway that connectsports in G to ports in F, as shown in FIG. 19. The same virtualMemory Mis associated with all the ports in G and all the ports in F,G.vM=F.vM=M. M holds the service request message jointly being sent bythe ports in G. Let us refer to this group-to-group pathway, as pathwayP. The agent a0 in P dispatches the service request message in G.vM onlyafter all the parent-cells of ports in G have completed their respectivecomputations and contributed to the joint service request messagewritten in G.vM. This is called dispatch coordination. At the time themessage is dispatched a0 also sends a signal to eb.f₁ via agent a2, toinform the eb cell that a message has been dispatched.

Once dispatched, agent a1 receives the signal sent by a0 and on receiptof this signal synchronously delivers the message in G.vM=F.vM to thefunctionPorts in F that satisfy an a priori defined security condition.FunctionPorts in F receive message delivery signals with no more than 2or 3 nanoseconds delay between them. This is called deliverysynchronization. Once delivery signals have been broadcast to all portsin F, a1 sends a signal to eb.f₂ via agent a3, to inform the eb cellthat a message has been delivered. When the eb cell receives signals atboth ports eb.f₁ and eb.f₂, it installs appropriate message sending andmessage receiving events into the causalnet corresponding to the messagejust transmitted through the group-to-group pathway.

The reply message is jointly written into the same virtualMemoryF.vM=G.vM=M by the parent-cells of functionPorts in F. The same fouragents in the pathway again perform dispatch coordination, deliverysynchronization and signaling to the eb cell, for the reply message fromF to G. We assume, in general a port-group may contain at most 16 ports.Message transmission in a dm-pathway occurs in a similar manner. Theonly difference is, message is broadcast via transmission lines fromG.vM to a collection of virtualMemories [F₁.vM, F₂.vM, . . . , Fk.vM],for some k≧1, associated with functionPort groups [F₁, F₂, . . . ,F_(k)] where each F₁ is in a distinct SMP, as shown in FIG. 24.

Each cell C in a cell-group simply evaluates C.p.protocol, whichspecifies the P.protocol component of the group-to-group pathway, P thatconnects the cell-group to another cell-group. C executes C.p.protocolin parallel with other cells in that cell-group, as soon as each cellcompletes writing its contribution to the message to be sent into thevirtualMemory of P. Protocol executions by cells in the cell-group maynot all happen synchronously, since computations performed by the cellsare not synchronized to each other. As mentioned earlier, agents in thepathway coordinate this parallel protocol execution and guarantee thatthe joint service request message is synchronously delivered to thereceiving functionPorts only once and the eb cell is appropriatelynotified.

Application programmers do not have to specify dispatch coordination,delivery synchronization or eb-cell notifications in any of the programsthey write. All needed pathways and communication protocols likely to beused in any parallel program are predefined and compiled codes for theseprotocols are provided by TICC™-Ppde. Once a pathway is installed,synchronization, coordination and monitoring are automatic. We refer tothis as self-coordination, self-synchronization and self-monitoring(details in Sections 1 and 7 of Chapter 3).

(21). ScratchPad Memories: Each cell in a cell-group runs in its ownassigned CPU, which is distinct and not shared with any other cell in anapplication. When cells in a cell-group processes a service requestmessage in a virtualMemory, M, common to all cells the cell-group andjointly delivered to all of them, they may encounter a need tocoordinate their respective computations with each other. They do thiscoordination, by exchanging data with each other, while responding tothe service request, through a scratchpad provided by their commonvirtualMemory M. Implementers should incorporate into methods used bycells in such cell-groups, mechanisms to coordinate their respectivecomputations by exchanging data through the scratchPad. Communicationsamong cells in such a cell-group will occur via the scratchpad, and mayoccur in the CSP mode [Hoare 10-12].

(22). Efficient Low Grain-size Executions: Organization of TICC™-Ppdeallows for efficient high speed executions because of (i) elimination ofoperating system intervention in communications, process and pthread(parallel thread) management, coordination, synchronization, interrupthandling, data protection and security enforcement; (ii) elimination ofneed for scheduling and synchronization sessions in all communications,process activations, pthread and method invocation and executions; (iii)very low communication latencies; (iv) parallel simultaneous messageexchanges; (v) elimination of sequential buffers in asynchronouscommunications; (vi) precisely timed program and protocol executions and(vii) minimized memory contention made possible by the virtualMemoryorganization (Section 6.2 and Section 8 of Chapter 3). Sincecommunication latencies are in ten to a few hundreds nanoseconds range,it is possible to run parallel programs with good efficiencies (90% to100%) at very low grain sizes of the order of one to a hundredmicroseconds in massively parallel computations.

(23). Built-in Data Security and Protection: All processes and pthreads(parallel threads) are activated only through message exchanges, andmessages are delivered to recipients only if each (message, recipient)pair satisfies a priori specified security conditions. Cells are givenaccess to data they process only if messages have been delivered to themand only when they process, build and/or send out messages. Each cellexecutes its own message exchange protocols, as soon as a message isready to be sent. All security checks are built into communicationmechanisms. Latencies quoted in this paper include in them times neededto check security conditions. There is no distinction betweencomputation and communication. There are no monitors or schedulers andno dynamic link libraries. Thus it is practically impossible for anyintruder to track or interfere with either message exchanges orprocess/pthread activations occurring in a system. Thus, TICC™-Ppdeprovides built-in data security and protection.

(24). Arbitrary Scalability: As long as interaction overhead caused byscaling is small, when compared to program execution times, parallelprograms in TICC™-Ppde are arbitrarily scalable. What is unique toTICC™-Ppde parallel programs is that interaction overhead may be definedprecisely relative to the structure of a TICC™-network. Let N be aTICC™-Network of cells and pathways and n_(max)(N,C) be the maximumnumber of messages exchanged by cell C in N in any one of its pollingcycles. Let n_(max)(N) be the maximum of all n_(max)(N,C) for C in N:n_(max)(N)=Maximum{n_(max)(N,C)|CεN}. Let σ(N) be the number of cells innetwork N, and let N′ be the scaled up version of N with ν(N′) cells.Then the requirement for arbitrary scalability is: n_(max)(N′) isindependent of the scaling factor, α=[ν(N′)/ν(N)]. The value of a couldrun into millions, if this condition is satisfied. This essentially saysthat communication and coordination overhead per cell should notincrease as the scaling factor increases, in order for a parallelprogram to be arbitrarily scaled.

(25). Ideal Environment for Multi-core Chips: TICC™-Ppde introducesseveral programming abstractions, many of them new to programmingtechnology. Software tools associated with the abstractions facilitatebuilding of parallel programs that may run in a diversity of multi-corechips. Roles played by the abstractions in parallel program developmentand execution in multi-core chip environments, and tools associated withthem are itemized in the following list.

Abstractions 1: Cell & Pathway: These abstractions are not new, buttheir particular incarnations in TICC™-Ppde are new. They isolate andprotect computations performed by each CPU in a multi-core chip andprevent mutual interference among computations performed simultaneouslyin parallel by distinct CPUs in the chip. Pathways also isolate andprotect messages, and prevent mutual interference among asynchronousmessages exchanged simultaneously in parallel between distinct groups ofCPUs in the chip. Tools are provided to define, install and update cellsand pathways, manage CPU assignments to cells, cell activations in theassigned CPUs and to control access to virtualMemories by CPUs, allwithout need to invoke an Operating System. Subclasses of pathwayslikely to be used in any parallel programming application are predefinedin TICC™-Ppde. Implementers have to define only unusual pathwaysubclasses not already defined in TICC™-Ppde. Every cell subclass usedin an application should be defined by the implementers.

Abstractions 2: Attachment, Tuning, Port & Agent: Only attached ormutually tuned hardware/software components may share each othersmethods and data, and exchange signals between each other. This not onlyenforces cell, CPU and message isolation, but also facilitatesself-synchronization and self-coordination of computations andmessage/signal exchanges. Attachment and tuning as programmingabstractions are new to programming. The concept of software ports andagents is not new. however, the particular characteristics of ports andagents in TICC™-Ppde are unique to TICC™-Ppde. Attachments and tuningsare performed automatically by TICC™-Ppde from definitions of cells andpathways. Implementers do not have to specify them. Subclasses of portsand agents likely to be used in any parallel programming application arepredefined in TICC™-Ppde. Implementers have to define only unusual portand agent subclasses not already defined in TICC™-Ppde.

Abstraction 3: VirtualMemory: It is common in computing systems toassociate dedicated hardware memories with hardware systems. But theconcept of using dedicated virtualMemories as software abstractions ofhardware memories used in software systems is new. This concept wasfirst introduced by Gopinath [21] (even though this terminology was notused) and later adapted by this inventor, with some enhancements, forparallel program development and execution in TICC™-Ppde. Real memoriesare allotted to virtualMemories during compile or run time.VirtualMemories simplify parallel programming with multi-core chips anddesign of multi-core chips, as explained in Section 8.2 of Chapter 3.

VirtualMemories hold messages and enforce cell/message isolation. Inaddition they enforce data protection, data security, and provideexecution environment for methods that are used to process and createmessages, minimize memory interference (Section 6.2 and 9.2, of Chapter3), and provide scratchpad for cells in cell-groups to coordinate theiractivities. TICC™-Ppde provides tools to define, declare, install andupdate virtualMemories. Subclasses of virtualMemories likely to be usedin any parallel programming application are predefined in TICC™-Ppde.Implementers have to define only unusual virtualMemories subclasses notalready defined in TICC™-Ppde.

As explained in Feature 3 and Feature 6 below (and Section 8.2 ofChapter 3), virtualMemories enable a new approach to memory organizationin SMMC (Shared-Memory Multi-core Chips) that simplify SMMC design andimprove their performance efficiency. Each CPU in SMMC is implementedwith a minimal amount of private memory with sizes in the range of 10kilo-words to 1 mega-word and no cache memory or any other speed-upmechanisms. However, the SMMC has a pool of hardware Shared-MemoryModules, SMMs, ranging in size from 100 kilo-words to a few giga—words.TICC™-Ppde assigns an SMM to each virtualMemory defined in anapplication either during compile time or during run time. Duringparallel program executions, CPUs that run cells are dynamicallyconnected to the SMMs already assigned to the virtualMemories used bythose cells. Ports in the application dynamically schedule making andbreaking of such connections between CPUs and SMMs as and when needed(details in Section 8.2, Chapter 3). Each SMM may service simultaneouslyonly about 8 to 16 CPUs. This organization reduces dramatically memoryinterference in large scale SMMC containing 256 or more CPUs and alsointrinsically contributes to data security and protection.

Abstractions 4: CCP and Protocol: A significant abstraction, which infact makes integration of all other abstractions possible, is CCP(Causal Communication Primitive). CCPs are used in TICC™-Ppde to definecommunication protocols, which, when executed, cause signals to travelover pathways associated with those protocols. They enablehardware/software components to exchange signals dynamically andprogrammatically, thus isolating them and yet enabling them tocollaborate with each other. CCP induced signal exchanges synchronize,coordinate and manage asynchronous software/hardware components verymuch like start/completion signals synchronize, coordinate and manageasynchronous hardware components. Protocols likely to be used in anyparallel programming application are predefined in TICC™-Ppde.Implementers have to define only unusual protocols not already definedin TICC™-Ppde.

CCPs eliminate the need for using an Operating System to managehardware/software interactions, resource allocation, process/threadmanagement, interrupt handling, synchronization, coordination andsecurity enforcement. Since CCP itself can be a machine instruction,CCPs eliminate the distinction between computation and communication inTICC™-Ppde. The same cells that perform computations also perform allneeded communications. No support is needed from an Operating System toexchange messages/signals, no monitors are needed to manageprocesses/threads, no semaphores [23, 24] are needed for softwarecoordination, and rendezvous technique [10,12] is not needed forsoftware synchronization. Use of CCPs speeds up communicationsenormously and naturally leads to the TICC™-Ppde parallel processingarchitecture. Concept of using CCP as a basic programming languageprimitive is new to programming technology and implementing it as amachine instruction is new to design of CPUs.

Abstraction 5: TIP: TIPs are Thread Interaction Protocols. Each port C.pattached to a cell C in an implementation has a TIP, C.p:TIP(), definedfor it. TIPs perform the following functions: (i) They facilitatesoftware development through abstract specifications of interactionsamong ports in an application and progressively refine the abstractspecifications to final implementations. (ii) They isolatecommunications from message processing and message building computationsin each cell. (iii) Isolate parallel computations performed by differentcells. (iv) Allow automatic derivation of modularized event based ALLEOPmodels for implementations at various stages of refinements. (v) Enableflexible use of ALLEOPs for formal verification of an implemented systemat various stages of refinement. (vi) Enable SMS (Self-MonitoringSystem) organization. TICC™-Ppde provides tools to define, install andupdate TIPs in implementation specifications, refine them, and deriveALLEOPs and traces, at each stage of refinement, from givenspecifications. As a programming abstraction, TIPs are new toprogramming technology. There is a total of 10 different kinds of TIPs,five of them synchronous TIPs and the other five asynchronous TIPs. Itis the responsibility of implementers to define a TIP for every port inan application, in a manner consistent with TIP definition formats inTICC™-Ppde and intended functionality of the TIP in the application thatis being implemented.

Abstraction 6: Synchronization:

Cycle Synchronization: Two TIPs, p:TIP() and q:TIP() associated with anytwo distinct ports p and q in an application are cycle synchronized ifevaluation of q:TIP() always begins after the evaluation of p:TIP() hasbeen completed, and the next evaluation of p:TIP() begins only after thecompletion of the previous evaluation of q:TIP(). Ports p and q maybelong to any two cells in the application; they may even belong to thesame cell. Cycle synchronization imposes coordination (ordering) ofactivities in an application. TICC™-Ppde provides facilities to cyclesynchronize any two TIPs associated with any two ports in anapplication.

Synchronization: The TIPs, p:TIP() and q:TIP() belonging to ports ofdistinct cells, are synchronized if their evaluation always begins atthe same time. TICC™-Ppde provides facilities to synchronize any twoTIPs associated with ports of any two distinct cells in an application.

TICC™-Ppde provides systematic methods to introduce cyclesynchronization and synchronization into a design or in to animplementation by suitable definitions of TIPs and pathways. TICC™-Ppdealso provides methods to introduce these synchronizations, as an afterthought, at any stage of refinement with no need to change any of therefinements done up to that point (Section 6.6 of Chapter 3). We callthe methods used for such after-thought synchronizations, ad hocsynchronization methods.

All synchronization and coordination methods used in TICC™-Ppde are newto programming technology and unique to TICC™-Ppde.

Abstraction 7: CIP: CIPs are Cell Interaction Protocols. A CIP is acollection of all TIPs defined at the ports of a cell together with aninitialization procedure for the cell. CIP specifies the order in whicha cell polls its ports cyclically. There are two kinds of CIPs: Thosethat invoke the TIP defined for a port immediately on sensing thepresence of message at that port, and those that put the ports withmessages into an ordered-ports-list according to an ordering criterionlocal to the cell, and then respond to the ports by executing theTIP-bodies at the ports in the order the ports appear in the list. It isalso possible that a cell responds to some ports immediately instead ofsorting it first and sorts other ports.

Each CIP is associated with a unique process that runs, in a unique CPUin parallel with all other processes in a parallel processing system. Wewill refer to this CIP-process of cell C as C:CIP(). C:CIP() executescyclically the TIPs at the ports of C that have messages delivered tothem and continues its operation until it is terminated or suspended.CPU that runs C:CIP() is assigned to cell C by TICC™-Ppde is referred toby the term, C.cpu. Also, each cell is activated in its assigned CPU byTICC™-Ppde. CIP-processes are the only processes in TICC™-Ppde parallelprogram execution. Their scheduling, activation in a CPU, suspension,resumption, synchronization and coordination are all managed entirely byTICC™-Ppde without need to use an operating system.

The concept of polling to recognize receipt of service requests andrespond to them in some order is not new. It is widely used in allsoftware systems. But the particular incarnation of this service in CIPsis unique to TICC™-Ppde.

Abstraction 8: TICC™-Network: This specifies in a graphical form cellsused in an implementation and pathway interconnections among portsattached to the cells. TICC™-Network implicitly specifies and enforcesall synchronization and coordination of parallel computing activitiesthat occur in an application. Implementer has the responsibility tospecify the TICC™-Network used for an application. Once this is doneimplementers are totally relieved of all responsibility to incorporateinto their parallel computer programs any facilities for coordination,synchronization or any kind of monitoring of parallel computations whilean application is running.

TICC™-Network provides the right kinds of abstractions to specify andanalyze control structures of parallel program executions. Just as thedata-structure abstraction makes it possible to run the same sequentialprogram with different data-structure definitions in order to optimize asequential program as long as the structure of the sequential programmatch with structure of the data-structure, the TICC™-Network structuremakes it possible to run the same set of parallel application programswith different TICC™-Networks in order to experiment and optimize aparallel program organization, as long as the initialization routines ineach C: CIP () in an application match with the structure ofTICC™-Network.

Using a graphical representation to capture the control structure ofinteractions among components of a system is not new. But the specificincarnation of TICC™-network with its unique interpretation inTICC™-based parallel software systems is new.

Abstractions 9: ALLEOP & Trace: The manners in which these twoabstractions are defined and used are new and unique to TICC™-Ppde.TICC™-Ppde provides the tools to derive ALLEOPs automatically fromimplementation specifications and use them to validate software systems.The concept of a trace is not by itself new. The term trace is used torefer to a description of what happens in a particular run of a programexecution. Different programming disciplines use different syntacticstructures or graphical tools to specify traces. TICC™-Ppde traces havethe unique characteristic that they not only specify all of what mayhappen in any run of an application, but also define the logicalsemantics of parallel computations. Traces are derived automaticallyfrom ALLEOPs and logical input/output characterizations of actions.Actions may be pthreads (parallel threads), or individual programstatements or conditions. TICC™-Ppde provides the tools necessary tointeractively define action characterizations and use them toautomatically derive traces from ALLEOPs (Section 2 of Chapter 3).TICC™-Ppde also provides methods that use ECT-networks (EventCharacterization Table networks) automatically derived from traces tovalidate properties of implementations.

Abstractions 10: SMS, Causalnet & eb-cell: Causalnets are abstractionsof traces; they contain only causal chains of communication events thatoccur in traces. Causalnet for an application Ap is built by the SMS(Self-Monitoring System) of TICC™-Ppde, while Ap is running, in parallelwith Ap. Agents in each pathway, P, in application Ap send signals to aspecialized cell of SMS, called Event Builder cell (eb cell), connectedto pathway P, while signals are traveling along P. Each pathway P isserviced by a dedicated eb cell. A given eb cell may service severalpathways. Signals received by the eb-cell of P instruct the eb-cell toinstall into a growing causalnet of the application, message dispatchand delivery events occurring in P. The eb cell installs the dispatchand delivery events while messages delivered by P are being processed byparent-cells of ports that received them. Signaling of eb cell occurs inparallel with signal transmission over the pathway, and dispatch anddelivery event installations occur in parallel with message processingdone by the message receiving cells, in a manner that preventsinterference between timings of SMS events and timings of applicationevents. There are four activities that run in parallel while a growingcausalnet is being built by the eb cell in SMS: (i) activities of allcells that run in the application, (ii) activities of agents in pathwayssignaling the eb cell in SMS, (iii) activities of eb cell while theyupdate the growing causalnet with new message dispatch and deliveryevents, and (iv) activities of ea cell of SMS that analyze the growingcausalnet (see Abstractions 11 below).

Each eb cell uses the local time of the CPU that runs that ea cell todetermine when given message dispatch and delivery events occurred in anapplication. Since local times of all CPUs that run eb cell aresynchronized to a standardized global clock, all timings associated byeb cells with event instances in the causalnet will be synchronized tothe same global clock. CPUs that run other cells in the application mayuse different local clocks not synchronized either to the global clockor to each other.

Specification of an application implementation automatically defines theSMS structures needed for that application. SMS so defined for anapplication is automatically invoked and used by TICC™-Ppde todynamically monitor every run of that application. Applicationimplementers do not have to write any programs to facilitate this. EachSMMC (Shared-Memory Multi-core Chip), X, in a distributed-memorycomputing grid, interconnected by a TICCNET™, will have its own uniquelocal SMS, X: SMS (). The causalnet built by X: SMS () will reside inthe local shared-memory of x. TICC™-Ppde can integrate the causalnets indifferent SMMCs of a distributed-memory computing grid and display anyportion of it centered on given cells or ports in an application, usingTICC™-GUI (Graphical User Interface), as and when needed.

Abstractions 11: SMS & ea cell: SMS uses specialized cells, called EventAnalyzer cells (ea cell), to constantly monitor a growing causalnet,while it is being created, during each run of an application. Theobjective is to identify and report errors and pending errors in thegrowing causalnet as per definition in Condition-1. Ea cells may alsomonitor the causalnet to identify occurrences of a priori defined eventpatterns in the causalnet and issue alerts. Eb cells communicate with eacells by exchanging signals using CCPs, in order to coordinate their owncausalnet updates with causalnet analysis performed by the ea cells. SMSis a built-in part of TICC™-Ppde parallel program execution mechanism.

(26). Uniqueness of TICC-Ppde abstractions: The abstractions,TICC-Network, Cell, Port, Agent, VirtualMemory and Pathway areabstractions of system components. We will call themsystem-abstractions. The abstractions, Pthread, TIP, CIP, ALLEOP andCausalnet are process abstractions. These are quite unlike conventionalprogramming abstractions such as variables, blocks, assignments,declarations, conditional statements, while-loops and data-structures,and conventional process abstractions like methods, functions,co-routines, and sub-routines, and conventional-system abstractions suchas class, object and message. Conventional abstractions do not identifyand relate directly to system components and processes, as TICC™-Ppdeabstractions do. Conventional system abstractions do abstract systemcomponents, but mapping classes to system components in implementationsis quite a non-trivial task.

Summary: All of the above programming abstractions and methods used inTICC™-Ppde parallel program development, validation, execution andself-monitoring are unique to TICC™-Ppde. The abstractions and methodstogether provide the tools necessary to install and manage instances ofthe abstractions in parallel programs and build formally verifiedparallel software systems for any application, including real-time cyberphysical applications, all of which may run in a diversity of multi-corechips.

(28). Significant Features of TICC™-Ppde:

Feature 1: System Design and Implementation: TICC™-Ppde shifts the focusof system development from programming to system decomposition,interaction specification and verification. Programming throughrefinements becomes a trivial task once system organization andinteraction specifications are in place, and verification follows as anatural consequence of the implementation.

At present, we do not have systematic methods for system decomposition.One faces this problem in the specification of any complex system,software or hardware, and physical or social systems. Perceivedrealizability conditions always influence system decomposition anddesign. Allowing realizability conditions that depend on programmingidiosyncrasies to guide system decomposition and design is, however, nota good practice. By shifting the focus to system decomposition andinteraction specification, and delegating programming to successiverefinements of an already defined design, TICC™-Ppde attempts to avoidthis problem.

Feature 2: Integrated Environment: TICC™-Ppde performs CPU assignmentsto cells, cell activations in assigned CPUs, parallel processmanagement, pthread (parallel thread) management, communications,interrupt management, security enforcement, synchronization andcoordination, without having to invoke an operating system or any othersoftware to perform any part of these services. In the current prototypeimplementation, TICC™-Ppde uses the operating system only for memorymanagement, cache management and access to secondary storage devices,input/output and internet access. As mentioned in Feature 3 cachememories and all other kinds of speed-up ornamentations commonly used inCPU designs can be totally dispensed with in SMMCs (Shared-MemoryMulti-core Chips) used to run TICC™-Ppde programs. All servicescurrently provided by an operating system to TICC™-Ppde may then beincorporated with in TICC™-Ppde itself. Thus TICC™-Ppde provides anintegrated parallel program development, verification, execution andrun-time monitoring environment that is ideally well suited to develop,validate, run and monitor parallel programs in SMMC or in a computinggrid consisting of several SMMCs.

Feature 3: TICC™-GUI: This displays graphical representations ofsegments of TICC™-networks anchored at given cells, and segments ofALLEOPs anchored at given ports or cells, and segments of causalnetsanchored at given ports or cells. Examples of TICC™-network displaysappear in Chapter 3. TICC™-GUI provides facilities to examine the stateof any cell in an application, while it is running at time points atwhich the GUI polls for cell states in response to received servicerequests. It is practically impossible to display the state of a cell attime points which precisely coincide with the times when displayrequests were made. However, one could set break points and have thestates displayed when certain events occur. Introducing such breakpoints into an application A will however alter timings of eventsoccurring in A. Thus break points may be used only in a testing mode.GUI is useful both to document system implementation and for dynamicsystem monitoring. TICC-GUI is an integral part of TICC-Ppde.

Feature 4: Eliminating Cache Memories and Speed-up Techniques: Cachememories may be dispensed with for running TICC™-Ppde parallel programs.In our prototype implementations we found cache memories more of anuisance. With small grain-size executions, too much time was wasted incache replenishments and cache incoherence was often a problem. We hadto update data in main memories in order to avoid cache incoherence.Cache memories are not needed for high throughput program executions inTICC™-Ppde. High throughputs may be realized by arbitrary scaling of lowgrain-size parallel program executions in cells. Indeed none of theusual speed-up techniques such as, multiple instruction-streamexecutions [29], look-ahead scheduling [30], pipe-lined processing [31]and cached executions [32] are needed for high efficiency and highthroughput in TICC™-Ppde. In TICC™-Ppde each CPU is dedicated toservicing only one cell, using only the virtualMemories associated withthat cell. Each cell may execute only one TIP at any given time and TIPexecutions are uninterruptible (Section 5, Chapter 3). The time taken toexecute a TIP including both computation and communication may be assmall as 1 to 100 microseconds. There are no scheduling,synchronization, coordination and monitoring overheads. Thus, there isno natural context in TICC™-Ppde to profitably employ any of the abovespeed-up techniques. This has two benefits: (i) it simplifies CPUdesigns in SMMC (Shared-Memory Multi-core Chips) thereby increasing CPUdensity in chips, and (ii) it enables event timing predictions with intight bounds.

Feature 5: Ideal Environment for Developing Validated Self-MonitoringCyber-physical Real-time Systems: Software execution with precisetimings within given bounds is a necessary and important requirement forbuilding cyber-physical real-time systems. TICC™-Ppde facilitates formalvalidation of software systems, automatic self-monitoring using SMS, andprediction of event timings with precisely defined bounds. It should beclear by now that TICC™-Ppde provides the ideal environment to develop,validate and deploy self-monitoring cyber-physical real-time systems,like for example auto-pilot of an aircraft or a space-craft system,automated multi-sensor applications, automated defensive/offensivecoordination in military vehicles, automated factories, robots, or anyother such time critical reactive system. It may also be used to buildsecure information systems like medical information systems orintelligence information systems or any data-base system. A significantmost widely used application for TICC™-Ppde is likely to be in personalcomputer systems with SMMC that guarantee privacy and protection againstall unauthorized intrusions and attacks.

Feature 6: Dynamic Flexibility and Mobility: TICC™-Ppde parallelprograms may be dynamically modified and updated, by changing pathwayconnections dynamically and by introducing dynamically new cells andpathways. See U.S. Pat. No. 7,210,145 B2 for in situ testing of newversions of cells in parallel with old versions with little or no changein normal operations. Program mobility in distributed environments isachieved by transferring entire contents of a virtualMemory in oneprocessor to other virtualMemories of other processors in distributedsystems.

Feature 7: TICC-CPUs: It is assumed in this invention, that each CPUwill have no cache memory or any other kinds of speed-up augmentationfor instruction execution. This simplifies CPU designs. But eachTICC™-CPU requires some special hardware facilities to facilitatehigh-speed parallel program executions and enforcement of systemsecurity. The first such facility allows the local clock of a CPUassigned to a cell, C, to be polled simultaneously in parallel by afixed finite number of (at most 16) other CPUs that may deliver messagesin parallel to port attached C. The second such facility implements CCPas a machine instruction. The third pertains to interrupt handling. Andthe fourth pertains to shared-memory implementation that exploits thevirtualMemory organization to minimize memory interference anddramatically increase system security. All of these facilities may beimplemented as described in Section 8 of Chapter 3, without any need touse an Operating System.

TICC™-CPU design eliminates the need to integrate SMMC (Shared-MemoryMulti-core Chips) with huge multi-gigaword sized shared-memories withattendant problems of data security and memory contention. The schemeproposed here decreases considerably memory contention at run time.Also, absence of a single huge shared-memory and use of virtualMemorieswith strictly limited capability for sharing, provide increasedsecurity, privacy and data protection, since (i) each agent deliversmessage in a virtualMemory to a port only if the port satisfies a priorispecified security conditions specified for that message and port, and(ii) each port in TICC™-Ppde protects messages in its virtualMemory,giving access to its virtualMemory only to its parent-cell and only attimes when the parent-cell is ready either to send a message or ready torespond to a securely delivered message/signal. In addition, TICC™-Ppdehas no centralized scheduling mechanism, and no centralized process andmethod activation directory (Dynamic Link Library). These featurestogether erect formidable barriers for potential intruders to break intoa system and track system operations.

DETAILED DESCRIPTION 1. Causal Communication Primitives (CCPs) andAdaptation of RESTCLK Pathways

For convenience and continuity, we describe in this section some of theconcepts and mechanisms introduced in U.S. Pat. No. 7,210,145 B2, byinventor, Chitoor V. Srinivasan, but with a different perspective. Wealso describe in this section, the structures of simple TIPs (ThreadInteraction Protocols), CIPs (Cell Interaction Protocols) and simplecommunication protocols. Variations on these simple structures areintroduced later in Sections 3 and 4.

It is common practice in hardware systems to use signals to control,synchronize and coordinate activities of hardware components. Insynchronous hardware, clock signals are used, and in asynchronoushardware start and completion signals are used. As explained in U.S.Pat. No. 7,210,145 B2, Gopinath [21] first proposed exchanging signalsprogrammatically between software/hardware components, and [Das, 19]first defined the structure of shared memory RESTCLK-pathways over whichsignals may travel. Gopinath and Das used short threads to send, receiveand process signals, and implemented their systems with time slicedconcurrency managed by an Operating System (OS). The signal exchangemechanisms defined by threads, were used to implement message exchangesin shared memory environments. Communication over a distributed networkwas done using a network facility, such as for example, ETHERNET[Spurgeon, 22].

Time sliced concurrent thread scheduling and activation introducednon-determinism into signal exchanges. Messages could not be deliveredwithin bounded latencies and messages were sometimes lost. TICC™ adaptsand modifies the framework introduced by Gopinath and Das to provideguaranteed parallel message deliveries with bounded latencies in tens tohundreds of nanoseconds range, for application to parallel programmingof shared memory and distributed memory systems in the context of an OO(Object Oriented) programming language.

Guaranteed programmatic exchange of signals between software/hardwarecomponents, at high speeds, allows software to directly control itsexecution in a hardware system, while preserving component isolation. InTICC™ we currently do this for all communications, assignments andactivations of cells in CPUs, process and pthread (parallel thread)scheduling and activations, interrupt handling, data protection,security enforcement, synchronization, coordination and self-monitoringin both shared-memory and distributed-memory environments. PrototypeTICC™-Ppde uses the operating system only for memory management, paging,caching, and input/output. It should eventually be possible to implementall operating system services in TICC™-Ppde itself.

1.1. CCPs and Programmatic Signal Exchange Signal exchange between pairsof hardware/software components, is programmatically specified in TICC™by using a new programming primitive called Causal CommunicationPrimitive, CCP. Each CCP has the form, X: z→Y, where z is a start orcompletion signal, and X and Y are software or hardware components. Eachtype of signal may have sub-types defined for it. CCP is like anassignment in that it assigns a signal to a component. But, unlike anassignment the effect of signal assignment might manifest only after acertain delay. In TICC™ the desired effect is ultimately either messagedelivery or message dispatch; hence the name, CCP.

Specifying signal exchange using CCP has several advantages: (i) just asassignments, CCPs may be freely embedded in to other programmingstatements and implemented as a machine instruction in a CPU, thusenabling programmatic signal exchanges with in a computation; (ii)flexibly organize program executions; (iii) eliminate the distinctionbetween communication and computation; (iv) use the same protocolinvocation formats for shared-memory and distributed-memorycommunications; and (v) make it possible to keep RESTCLK-pathwaystructures with only minimal changes, even though TICC™ signal exchangemechanisms and protocol execution mechanisms are different from those ofRESTCLK [Das, 19].

Each CCP is implemented by a 2-state or 4-state ndFSM (non-deterministicFinite State Machine). The FSMs are non-deterministic only in the sensethat state transitions are not defined for all inputs in every state ofthe FSM. It takes about 25 to 50 nanoseconds to execute a CCPimplemented in software in a 2-gigahertz computer with 100 megabits/secmemory bus. If implemented in hardware as a machine instruction, in a2-gigahertz CPU, it should take no more than 5 nanoseconds (estimated).

It takes only four 2-state ndFSMs controlled by CCPs for point-to-pointmessage transfers, it may take 10 or more 2-state ndFSMs fortransferring a message from one group of cells to another group of cellsin shared memory environments, depending on the number of cells in eachgroup (Section 7), and up to 24 or more 2-state and 4-state ndFSMs forsimilar message transfers in distributed memory environments usingTICCNET™. Incorporating the SMS mechanism into message transfersrequires four more 2-state ndFSMs (Section 7) for each sm-pathway. Itmay require 10 or more additional ndFSMs for a dm-pathway, depending onthe number of functionPort groups to which message is transmitted. Thus,as mentioned earlier, it should take only tens or hundreds ofnanoseconds for point-to-point and group-to-group message transfers ifCCP is implemented as a hardware instruction.

Communication is reduced to a Turing computation [Turing, 20] performedby the ndFSMs, and becomes an integral part of computations performed bycells. Each cell transmits its message immediately as soon as it isready, via hardware/software pathways connected to its ports. There areno synchronization and scheduling delays. Multiple protocols may beexecuted by cells operating in parallel without mutual interference.However, each cell may at any time execute only one protocol. Allcommunications are asynchronous and they do not use sequential buffers.

It is necessary to explain how these are made possible and howcomputations and communications performed by each cell are organized,before the reader can see how the benefits outlined in Chapter 2 flowdirectly from this.

1.2. Pathway Protocol, TIP, Message Transmission and Computation

Cells use their ports to exchange messages with each other, via pathwaysthat interconnect the ports. Each port may be attached to only oneunique cell called its parent-cell (prevents port interference), andeach port may be connected to only one pathway (prevents messageinterference). There are three kinds of ports: generalPorts, g, throughwhich cells send out service requests to other cells (these are like theoutput ports of π-calculus Agents [Milner, 7,8,9]), functionPorts, f,through which they receive service requests from other cells and respondto them (these are like the input ports of π-calculus), andinterruptPorts, i, through which they receive, interrupt messages fromother cells (there are no π-calculus analogs for these). GeneralPort andFunctionPort are subclasses of the abstract class, Port. InterruptPortis a subclass of FunctionPort. Every Cell subclass should have at leastone of each kind of Port.

Each port holds the communication protocol to send signals over thepathway connected to it. This protocol is defined using concatenationsof CCPs having the form X:x→Y:y→Z where X, Y and z are components in apathway and x and y are signals. CCPs may appear in a protocol possiblyembedded in other programming language statements (Section 7). Protocolsare dynamically updated as the pathway is changed. Each pathway isdefined by a collection of interacting ndFSMs which execute the CCPs.Only the parent-cell of a port may execute the protocol associated withthat port.

Pathways and CSP Channels: Pathways in shared memory environmentscontain only software components, like CSP channels [Hoare, 10-12].Pthreads in TICC™-Ppde correspond to Communicating Sequential Processesin CSP. Unlike CSP (i) pathways allow group-to-group asynchronouscommunications with time synchronized message deliveries; (ii) dataexchange mechanisms among interacting pthreads are not coded into thepthreads; (iii) unlike CSP channels pathways do not block senders andreceivers; (iv) pathways transmit only signals; and (v) if messages aretransmitted then pathways contain virtualMemories, which hold messagesand pthreads to build and process messages. Real memories are assignedto virtualMemories during compile time or run time.

Signals traveling over a pathway eventually establish the context inwhich the message in its virtualMemory is delivered to intendedrecipients in the case of shared memory pathways (sm-pathways), ortransported to other virtualMemories belonging to intended recipients inthe case of distributed memory pathways (dm-pathways). For eachsm-pathway, the virtualMemory that holds the message, if there is one,is unique and private to that pathway. Similarly, for each dm-pathwayall virtualMemories in that pathway are private to that pathway. Nopathway may use the virtualMemory of another pathway.

We refer to sm-pathways with virtualMemories as Das-pathways, since theywere first introduced by Souripriya Das [Das, 19]. We use the termpathway to refer to both sm-pathways and dm-pathways.

1.3. Simple Sm-Pathways

Let us first consider some simple sm-pathways. The parent-cell of a portexecutes the protocol at the port, in order to transmit signals via thepathway connected to that port. While executing the protocol, theparent-cell uses only its local memory, and memories associated with thepathway components. Protocol execution will not invoke any method,pthread or process that is defined outside the protocol. Thus OperatingSystem (OS) is not used for message exchanges.

A simple sm-pathway shown in FIG. 1. Here, a software branch connects ageneralPort C.g of cell C to a functionPort D.f of cell D. In FIG. 1,signal requesting a service travels first through the branch from C.g toD.f, and then the response signal indicating completion of the requestedservice, travels back from D.f to C.g. Cells use their ports (alsosoftware components) only when they send out signals via the ports, orwhen they receive and respond to signals received at the ports. Twocells connected to two ends of a pathway, as in FIG. 1, may never usethe ports connected to that pathway at the same time. Signals travelover a pathway only in one direction at a time. These hold true for allpathways in TICC™.

Each port in FIG. 1 contains a 2-state non-deterministic finite statemachine (ndFSM), with states S (send) and R (receive), as shown in thefigure. All generalPorts g start with the initial state, S, and allfunctionPorts f with initial state, R (double circles in FIG. 1). Thepathway in FIG. 1 is [C.g, D.f]. The initial state of this pathway is[S,R]. In this initial state, the pathway is ready to send a signal fromport C.g to port D.f and port D.f is ready to receive the signal sent byport C.g. In the following, we use the convention, for any port oragent, x, x.state=x.ndFsm.state and x.input=x.ndFsm.input, where x.ndFsmis the ndFSM embedded in x. Similarly, for any port p,p.state=p.ndFsm.state and p.input=p.ndFsm.input, where p.ndFsm is thendFSM embedded in p. Also, we use g to refer to C.g and f to refer toD.f.

Logical characterizations of CCPs: This is shown in Table 1.Characterizations are presented in Hoare's [Hoare, 15}pre-condition/post-condition notation. Pre-condition for a CCP in Table1 may depend on the states of both signal sending and signal receivingports. Interpretations of the CCP characterizations (1) through (10) inTable 1 are described below.

Signal Transmission from g to f: (1): When port g is in state S itaccepts signal c (completion signal) as its input signal from itsparent-cell C. (2): While in state S with input c, the g sends outsignal s and moves to state R, while the port f that receives thissignal s is in state R. Port f accepts s as its input signal. (3): Portf moves to state S when its input signal s is sensed by its parent-cellD by executing the signal sensing test: f:mR?() (‘mR?’ for‘messageReady?’). If f.input=s then f:mR?() returns the truth value trueand f.state moves to S. (4): Else f:mR?() returns false. Signal s hereis referred to as the delivery signal. Sensing of a delivery signal by arecipient cell constitutes message receipt by that cell. Since f:mR?()does not change the value f.input, the delivery signal at f may besuccessfully sensed several times. As we shall see below f.input changesvalue only when D begins to send back its reply signal.

Reply Signal Transmission from f to g: (5): Cell D sends completionsignal c to f indicating, it has completed its task. This setsf.input=c. (6): When f.state=S, f.input=c and g.state=R, f sends startsignal s to port g and changes its state to R. This is the responsesignal from D. (7-10): Cell C may use one of two sensing tests toreceive the delivery signal s at its port g: g:mR?() or g:pR?() (‘pR?’for ‘pathwayReady?’). Notice, the delivery signal at g may be sensedonly once using the sensing g:mR?() test, since g.input is reset toφ(the empty symbol) after sensing. In both g:mR?() and g:pR?() tests,and g.state moves to S. Whereas g:mR?() test will succeed only once onsensing a delivery signal, g:pR?() will succeed repeatedly after thefirst sensing, since the state of g changes to S.

For any port p, whether p is a general or function port sensing of adelivery signal always moves p to state S. This has a specialsignificance, which we will later see in Sections 5.3 and 8.2.

Thread Interaction Protocols, TIPs: TIP (1) in Table 1 specifies thefollowing: If the pathway is ready then c executes the pthread g:x(), todo whatever it needs to do before sending a service request. Thispthread is defined in the cell C, g:x()≡C:x(g) and is executed in theprivate memory assigned to C. Immediately after executing g:x(), Cexecutes g:s() (‘s()’ for ‘send’), which causes the communicationprotocol (1) in Table 1 to be evaluated in the shared memory associatedwith g and f. This results in the delivery of the service request signals to port f.

TIP (2) in Table 1 specifies the following: When D senses the servicerequest signal sent by C to its port f by applying the f:mR?() test, Dbegins to respond to the received signal by executing the pthreadf:r()≡D:r(f) (‘r()’ for ‘reply’), which is defined in cell D andexecuted in the private memory of D. Immediately after completing theexecution of f:r(), D executes f:s(). This causes the communicationprotocol (2) in Table 1 to be evaluated, which results in the deliveryof the reply signal s back to port g. Sensing of this reply signal bythe parent-cell C of port g marks the end of the transaction, whichbegan when C sent its service request signal to D.

Restrictions Imposed by Pathway State Changes: At the beginning of thetransaction the state of the pathway is [S, R]. At the time the signalis sensed by cell D, the state of the pathway changes to [R, S]. In thisnew state, the pathway is ready to send back a reply signal. When thereply signal is sensed by cell C, the transaction is completed and thepathway state reverts back to [S, R]. These state changes enforce thefollowing restriction: C.g can send a second service request signal onlyafter the transaction has been completed and D.f can receive a secondservice request signal only after the first service request has beenresponded to. Successive service request signals may be sent through apathway only after successive transaction completions. This hold truefor all TICC™-Ppde pathways.

Mandatory Responses to Service Requests: Another general rule that holdstrue for all TICC™-Ppde pathways is that every service request isresponded to without fail via the same pathway through which the requestwas received. An exception to this general rule occurs in “one-wayring-streets” (Section 7.1). Every transaction takes place through adedicated pathway. Receipt of the response always resets the pathway toits initial state, even in one-way ring-streets.

Tuning: In each signal transmission session, each ndFSM in a pathway isalways in a state in which it is ready to receive and immediatelyrespond to the signal sent by another ndFSM. This is true for all TICC™pathways, however complex they are, and however many ndFSMs are embeddedin them. This is called tuning. Tuning eliminates the need forsynchronization sessions during signal transmissions and speeds upsignal transmissions considerably.

NdFSMs in a pathway are tuned to each other by (i) setting them toappropriate initial states. (ii) When a message (signal) is sent one waythrough a pathway it resets the initial state of the pathway to a newstate in which the pathway is ready to transport the response signal theother way. (iii) Sending the response signal through the same pathwayalways resets the pathway to back to its initial state. (iv) Tuning ismaintained by requiring that every transaction initiated through apathway should be completed by sending a reply signal through the samepathway, and (v) by requiring that a new transaction may be initiatedthrough a pathway only after the current transaction over that pathwayhas been fully completed.

Integration of Computation & Communication: Computations andcommunications are both performed by the same cell. Computations occurby executing pthreads. Communications occur by evaluating protocols.Computations are defined by sequences of statements in a programminglanguage. Protocols are defined by sequences of CCPs, which may beembedded in programming language statements. Compiled codes for programsthat define computations, and protocols that define communications, areno different from each other, since each CCP may itself be compiled intoa machine instruction. Thus, there is no distinction between executingpthreads to perform computations, and executing protocols to performcommunications. They are both invoked and executed by cells when theyexecute TIPs. Every port of a cell has a TIP defined for it. TIPs areexecuted only by the parent-cells of the ports at which they aredefined.

It should, however, be noted, no protocol evaluation will occur in themiddle of a pthread execution. Always protocols are evaluated only afterpthread executions have been completed and messages are ready to besent. They are never interleaved with each other. In this sense, TIPsisolate computations from protocol evaluations.

A TIP at a port C.p of a cell C has the form,C.p:TIP()=C.p:<guard>?(){C.p:tip();}. If C.p:<guard>?() is true at thetime C.p is polled, then C executes the C.p:tip(), else C skips the portC.p. We refer to C.p:tip() as the TIP-body.

Polling: Each cell polls its ports cyclically in some order. Pollingorder does not determine the order in which ports of a cell areserviced, since a service is performed only if a delivery signal issensed at a port at the time it was polled, and signal delivery timesand polling times are not synchronized to each other; communication isasynchronous.

1.2.1. Simple Das-Pathways with VirtualMemories

FIG. 2 shows a Das-pathway, with virtualMemory M. TIPs at the portsconnected to M, protocols at the ports and CCP characterizations foragents and ports in FIG. 2 are shown in Table 2. The pathway has twoagents, a0 and a1. Each port gives access to its parent-cell to data invirtualMemory M that is connected to it, only if the state of the portis S. Data is protected and preserved in the virtualMemory until accessis given and the data is used. Agents in the pathway in FIG. 2 routesignals around the virtualMemory, as needed.

In Table 2, the pthreads, g:x()≡g:msg():x(g) and f:r()≡f:msg():r(f).These pthreads are defined in the message subclasses of messages writtenby parent-cells of g and f in to the virtualMemory M. We refer to thevirtualMemory M also by p.vM=f.vM, since M in FIG. 2 is uniquelyassociated only with these ports. Here, M provides the executionenvironment for the pthreads, and the virtualMemory is a part of theshared memory environment of both cells c and D. The structure of thevirtualMemory that allows for this kind of activity is described inSection 6.2.

Cell D in FIGS. 1 and 2 may not sense the signal delivered to it at thetime it was delivered; it is possible that D was servicing one of itsother ports at that time. Eventually, when cell D polls its port D.f andevaluates the guard, D.f:mR?() in the second TIP of Tables 1 and 2, itwill sense the delivery signal at D.f, if there is one. Cells never misssensing any signal delivered to any of their ports. Signals missed inone polling cycle are caught in the ensuing cycle. CCP characterizationsgiven in Table 2 are similar to the ones in Table 1.

1.2.2. Correctness of Transactions and Implementations

Let us suppose that m is the service request message sent by g and m′ isthe response message sent back to g by f. As in the case of FIG. 1,transaction will end at the time port g senses the delivery signal forthe reply message, m′. Let us suppose m′ was delivered to g at time t₂and m was sent by g at time t₁, t₁<t₂. The transaction between ports gand f is correct if the messages m and m′ satisfy an a priori definedrelation, R_([g,f])(m,m′), where R[g,f] is the name of relation that isspecific to ports [g, f], and in addition (t₂−t₁)≦Σ_(max)(g,f) holdstrue, where τ_(max)(g,f) is the maximum time it may take for thetransaction between g and f to complete. In cases where no messages areexchanged, as in FIG. 1, only the timing condition given above shouldhold true.

Well-matched Ports: Ports g and f are well-matched iff and only ifR_([g,f])(m,m′) and (t₂−t₁)≦τ_(max)(g,f) hold true for all transactionsbetween g and f, when messages (m,m′) are exchanged, and(t₂−t₁)≦τ_(max)(g,f) holds true when no messages are exchanged.

Correctness of an Implementation: An implementation is correct iff allpairs of ports in the implementation that are connected by pathways arewell-matched.

1.2.3. An sm-Pathway with Fork and Join Operations

Port-groups & Agents: FIG. 3 shows a simple pathway with an agent, a0.The agent broadcasts a time-synchronized signal to both ports in [D₁.f,D₂.f]. Ports of the same kind (i.e., all generalPorts, all functionPortsor all interruptPorts) attached to distinct cells and connected to thesame agent in a pathway form a port-group. Thus, ports [D₁.f, D₂.f] inFIGS. 3 and 4 constitute a port-group. Even though signals are deliveredto ports D₁.f and D₂.f at the same time, since cells operate in paralleland cell activities are not synchronized with signal deliveries, D₁ andD₂ may not sense and respond to delivery signals at D₁.f and D₂.f at thesame time. Eventually D₁ and D₂ will each sense the delivery signal andrespond to it, each at its own time. Agent a0 will send a responsesignal back to C.g, only after receiving completion signals from bothD₁.f and D₂.f. We refer to this as dispatch coordination. The AgreementProtocol method a0:AP[c₁,c₂]* in the 2nd protocol in Table 3 enforcesdispatch coordination. Thus, agent a0 thus does time synchronized signaldelivery to the port-group [D₁.f, D₂.f] and coordinated signal dispatchfrom [D₁.f, D₂.f].

Coordination of parallel protocol executions: Evaluation of protocol (2)in Table 3 proceeds as follows: Both D₁.f and D₂.f have similarprotocols: We use p.protocol to refer to the protocol at a port p.

D₁.f.protocol=[D.f:c₁→a0:AP[c₁,c₂]*:s→C.g], and

D₂.f.protocol=[D₂.f:c₂→a0:AP[c₁,c₂]*:s→C.g].

These protocols are evaluated, respectively, by cells D₁ and D₂. Both D₁and D₂ start evaluating their, respective, protocols in parallel, butnot necessarily synchronously. After executing the CCPs, D₁.f:c₁→a0 andD₂.f:c₂→a0 that precedes AP[c₁,c₂]* in D₁.f.protocol and D₂.f.protocolboth D₁ and D₂ evaluate the agreement protocol method a0:AP[c₁,c₂]* inparallel. The condition a0:AP[c₁,c₂] will become true only after a0 hasreceived both signals c₁ and c₂, signal c₁ from D₁.f and c₂ from D₂.f.D₁ and D₂ keep evaluating a0:AP[c₁,c₂]* repeatedly until it becomestrue. As soon as a0:AP[c₁,c₂]* becomes true, one of the cells D₁ or D₂is non-deterministically chosen by a0 to execute the rest of theprotocol and the other is forced to stop its protocol execution.

Reader may verify that the segment of the protocol that followsa0:AP[c₁,c₂]*, is the same for both D₁.f.protocol and D₂.f.protocol.Therefore, on satisfaction of a0:AP[c₁,c₂]*, agent a0 in FIG. 3 sendsthe response signal, s, to port C.g, no matter who executed theprotocol. Thus, a0 coordinates parallel execution of different segmentsof the protocol by parent-cells D₁ and D₂ of ports in the port-group[D₁.f, D₂.f].

A Das-pathway with a virtualMemory similar to the pathway in FIG. 3 isshown in FIG. 4. Its associated TIPs and protocols are shown in Table 4.In this figure a1 does time synchronized message delivery andcoordinated message dispatch: a0 does message dispatch when a servicerequest is sent out, and message delivery when a response message issent back.

Networks in FIGS. 3 and 4 represent synchronized fork/join operations: Afork occurs when signal is sent by port g to the functionPort group, anda join occurs when the ports in the functionPort group send backresponse signals. We extend this notion of fork and join, to thesituation where a generalPort group containing more than one port sendsa joint service request to a functionPort group. Protocol for suchgroup-to-group fork and join operations are discussed in Section 7.

1.3. Shared Memory and Distributed Memory Pathways

Sm-pathways: Links that connect ports to agents or other ports arecalled branches. Links that interconnect agents are called h-branches(hidden branches). All components of a sm-pathway, ports, agents,branches, h-branches and virtualMemories, are software components. Theyall operate in the shared-memory environment of the pathway thatcontains them.

Dm-pathways: Agents and some ports in dm-pathways of the TICCNET™ arehardware components, each operating in its own local memory; branchesand h-branches in dm-pathways are signal transmission lines. Besidesagents, ports and virtualMemories, dm-pathways also have specializedhardware switches and routers embedded in them. Communication occurs intwo phases: (i) pathway establishment and (ii) signals/data exchange.Switches and routers are used only during pathway establishment. Atypical dm-pathway is shown in FIG. 24. Once established, a pathway iskept in place and repeatedly used until it is dismantled and a newpathway is established. Messages may be exchanged only through alreadyestablished dm-pathways. Signal and data exchanges through signal/datatransmission lines are managed through CCP executions. As in sm-pathwaysall agents and ports in a dm-pathway that exchange signals/data alwaysremain tuned to each other. No two dm-pathways share components, exceptswitches and routers, which are not used during message transmission.The TICCNET™ can accommodate thousands of distinct mutuallynon-interfering point-to-point and point-to-group dm-pathways givingrise to thousands of simultaneous parallel message exchanges.

Properties that sm-pathways and dm-pathways share in common are listedbelow in three categories. Some of the properties have been alreadymentioned.

TIP formats are Independent of Pathway Structure: (i) The communicationprimitives are p:s() (‘s()’ for ‘send’) and p:f() (‘f()’ for ‘forward’),where p is a port: f() forwards a received message to a port of anothercell, may be after some modifications; s() sends a newly formed message.The primitives p:s() and p:f() are used to invoke and evaluate theunique protocol, p.protocol=p.pathway.protocol, associated with the portp and p.pathway. (ii) p.protocol is dependent on the nature of thepathway connected to p. The protocol is different for differentpathways. (iii) The same communication primitives, p:s() and p:f() areused to invoke and evaluate p.protocol no matter which kind of pathwayis connected to p. (iv) Communication primitive p:s() or p:f() isevaluated immediately after message to be sent or forwarded becomesready. (v) Invoking and evaluating p.protocol causes signals to betransmitted over p.pathway, which in turn causes a message, if any, tobe delivered or transmitted to its recipient ports, also connected top.pathway. (vi) Only the parent-cell of p may invoke and execute thecommunication primitives, p:s() and p:f(). (vii) TIP formats at ports pare independent of the kinds of pathways connected to p. (viii) Finally,all components in any pathway that exchange signals remain always tunedto each other at all times. These properties eliminate the distinctionin software systems between shared memory and distributed memorycommunications and totally eliminate the need for scheduling andsynchronization sessions in communications, and thus significantly speedup message transfers.

Simultaneous Parallel Execution of Group-to-group Message Exchanges:Distinct parent-cells C_(i) of distinct ports C_(i).p belonging to aport-group G=[C₁.p, C₂.p, . . . , C_(n).p], n≧1, (Sections 1.3 and 7)constitute a cell-group. (i) Cells C_(i) in the cell-groupsimultaneously evaluate in parallel their designated segments ofC_(i).p.protocol, distinct segments being specialized to distinct cellsin the cell-group. Each such segment being a component ofG.pathway.protocol, where G.pathway is the pathway connected to ports inthe port-group G. Parallel execution of all segments together implementsthe group-to-group asynchronous message exchange over G.pathway (FIG.19). Agents embedded in G.pathway coordinate such simultaneous parallelprotocol segment evaluations (Sections 1.3 and 7). Agents also signalspecialized cells, called eb (Event Builder) cells which install messagedispatch and message delivery event that occur while a message is beingsent/forwarded over G.pathway. (ii) In a distributed memory environmenta generalPort group in one shared memory multiprocessor (SMP) maybroadcast through a dm-pathway in TICCNET™ a joint message to severalfunctionPort groups [F₁, F₂, . . . , F_(m)], m≧1, each F_(j) residing ina distinct SMP (FIG. 24). The broadcast message is transmitted inparallel to all the destination functionPort groups, and deliveredsynchronously to all recipient functionPort groups. The functionPortgroups send their replies back to the source generalPort group inmultiplexed mode, one after the other through the same pathway. Thismaintains mutual tuning of components in dm-pathways.

High-speed Parallel Message Exchanges: (i) In all pathways, all messagesare sent immediately as soon as they are ready. (ii) All agents andports in a pathway that exchange signals are always tuned to each otherso that the signal sent by one to another, is immediately received bythe recipient and responded to at the appropriate time, no matter howcomplicated the pathway might be. This eliminates the need forscheduling and synchronization sessions. (iii) No two pathways sharecomponents in common and thus no two parallel executions of distinctprotocols will ever interfere with each other. This holds true both forsoftware sm-pathways in SMPs and hardware dm-pathways in TICCNET™.Therefore, (iv) the number of messages that may be exchanged in parallelis limited only by the number of distinct pathways.

Mobility: Dynamic changes of connections to pathway destination portsmay occur in the middle of a transaction (Section 3.2) in sm-pathways.Consider a destination port q to which q.pathway is connected, withvirtualMemory q.vM. When pathway connection is transferred from thedestination port q, to a new destination port p, q.pathway becomes thenew pathway, p.pathway that is now connected to p, and q.vM becomesp.vM. Parent-cell of p may then read messages in the virtualMemory p.vMand execute pthreads and methods in p.vM to process and respond to themessages in p.vM. Once the parent-cell of p completes processing themessages and completes writing a response message in p.vM, the pathwayconnection is returned to port q, when p.vM becomes q.vM. Theparent-cell of q may then modify the response message in q.vM and sendit back to ports that sent the service request. This enables programmobility.

Pathway connections to ports that sent the service request cannot bechanged in this manner. Also, such dynamic changes of pathwayconnections cannot be made in dm-pathways. However, new pathways may beinstalled dynamically at any time, between dynamically formedport-groups both in sm-pathways and dm-pathways. By transporting thecontents of an entire virtualMemory over a dm-pathway one may obtainprogram mobility across dm-pathways.

1.4. TICC-Classes and Objects

TICC™ defines the following top level classes: Cell, Port, Agent,VirtualMemory, Branch and Message. We use the notation, cell, port,agent, virtualMemory, branch and message to refer to objects, which areinstances of these classes, all software components. As with Actors[Hewitt, 5,6] and π-calculus-Agents [Milner, 7,8,9], each cell is aninherently parallel software component that runs in its own assignedComPuting Unit (CPU). There are several differences between cells, andActors and π-calculus-Agents. We will describe them later.

Restrictions on Pathway Structure: No two ports belonging to the samecell may be connected by a branch and no two branches may connect twoports belonging to the same cell to agents in the same pathway unlessthe ports belonged to a port-vector (see Section 5.2).² In all cases acell cannot send messages from one of its ports to another one of itsports; this prevents possible deadlocks. However, distinct portsbelonging to distinct cells may be connected by branches to the sameagent. As mentioned earlier, such ports form ordered port-groups; [D₁.f,D₂.f] in FIGS. 3 and 4 is an example. No two distinct port-groups mayintersect with each other and no two ports belonging to the same cellmay ever be in the same port-group. All cells in any cell-group willalways reside in the same SMP. As we shall see in Section 7, theserestrictions make it possible to exchange messages between port-groupsthrough group-to-group pathways. ² For example see pathway in FIG. 19.Here the ports eb.f₁ and eb.f₂ are, respectively, connected to agents,a2 and a3 that belong to the same pathway. Here, [eb.f₁, eb.f₂] is aport-vector of the cell eb.

1.5. Cell Operations, CIP and Polling

Each cell C polls its ports, C.p_(i), for 0≦i≦n≧3, in some order, andsorts all ports with pending messages in to a sortedPortsList, based ona sorting criterion selected by the cell itself. For each port C.q inthe sortedPortsList, the TIP-body, C.q:tip(), is then executed one byone in the order the ports appear in the sortedPortsList. Cells mayattend to interrupt processing only between successive C.q:tip()executions. Interrupt messages may change the order of ports in thesortedPortsList, or change port priorities, or performsuspension/termination of CIP executions in an orderly manner, withoutviolating any of the TICC™-Ppde requirements. A suspended CIP willautomatically resume execution of the next C.q:tip() when interruptmessage is delivered again to the same interruptPort. Operating systemcannot interrupt activities of a cell; only other cells in anapplication may do so. Dynamic processor assignments to cells in ashared memory multiprocessor (SMP) are managed by TICC™-Ppde. Assignmentof cells to SMPs in a distributed computing system is done by users. TheCIP defined below is a process associated with a cell C that is run bythe CPU in an SMP assigned to C.

The collection of all TIPs defined at the ports of a cell, one for eachport, together with a cell initialization method is called the CellInteraction Protocol, CIP. Initialization and interrupt message handlingdescribed below illustrate the general control structure for CIPoperations. These will vary from cell to cell depending upon when aninterrupt message is recognized in a cell's polling cycle and the natureof the interrupt message. A CIP has the form,

void Cell::CIP( ){  initialize?( ){stopPolling=initialize=false;       i:pR?( ){i:s;( );}; init( );}}  while (

stopPolling){   i:mR?( ){ i:s( ).r( );}//i:r( ) is defined below in(1.2).   Notice, reply is sent first   sortedPortsList:clear( );  //puts polled ports with message delivery signals into sortedPortsList  poll&SortPorts( );   //executes p:tip( ) in the order ports p appearin sortedPortsList.   for (int j=0; j < sortedPortsList:size( ); j++){    sortedPortsList[j]:tip( );}}  prepareToTerminate( );}              (1.1)The pthread i:r()=i:msg():r(i) is defined in message subclass of themessage in the virtualMemory of the interruptPort, i. Let InterruptMsgrefer to this subclass. The definition of InterruptMsg::r() is shownbelow and discussed in the second paragraph following the definition.

void InterruptMsg::r(i){//selectOne selects the first true alternate intop down scanning.   Cell cell = i.parent;//parent of port i.  selectOne{ cell:suspended?( ){ cell.suspended=false}       suspend?(){cell.suspended=true;           prepareToSuspend( );}      terminate?(){ stopPolling=true;}         true{ setPortPriorities( );}}     (1.2)

Initialization: In the above CIP, initialize?() is the truth value ofthe local variable, Cell.initialize, of the cell and ‘i’ is theinterruptPort of the cell. A dormant cell C is activated in a processorselected by TICC™-Ppde by the first interrupt message delivered to C.i.In general, a dormant cell may be activated by the first messagedelivered to any of its ports. The protocol that delivers a messageperforms this activation (Section 7). Upon activation, if initialize?()is true then the cell sets initialize=stopPolling=false, sends anacknowledgement back to the cell that started it by executing i:s(), ifindeed it was activated by an interrupt message at port i, and afterdoing these, it performs initializations specified in init() and thenproceeds to the while-loop.

InterruptPort Servicing: In the while-loop, the cell first polls itsinterruptPort. If there is no interrupt message, it skips the port. Ifthere is, then it executes i:r()=i:interruptMsg():r(i) shown in (1.2).There are four cases to consider in selectOne in (1.2). (i) If cell:suspended?() is true then it means, the cell has been previouslysuspended. In this case, cell.suspended is set to false and the cellimmediately proceeds to execute the rest of the while-loop. (ii) Ifi:interruptMsg():suspend?() is true then cell.suspended is set to trueand the cell prepares to suspend itself and immediately release itsassigned processor; after doing these, the cell becomes dormant. Thenext interruptMsg delivered to the cell will automatically activate thecell in an available processor. When so reactivated, the cell will skipinitializations and proceed directly to the while-loop, sinceinitialize?() will then be false. (iii) If i:interruptMsg():terminate?()is true then the cell terminates operations at the end of the currentcycle of the while-loop and releases its processor, sincecell.stopPolling is set to true in this case. (iv) The default case ofselectOne in (1.2) is to assign priorities to the ports of the cell asspecified in the interruptMsg. These priorities are used by the ensuingpoll&SortPorts() method in (1.1). The suspend/resume operations here aremanaged by TICC™-Ppde without having to invoke the operating system.

Polling: After polling its interruptPort, the cell begins to poll itsother ports; sorts ports with pending messages into its sortedPortsListby executing poll&SortPorts(), and then executes p:tip() for each p inthat list in the order they appear in the list. The while-loop isrepeated until stopPolling becomes true. Polling cycles are notsynchronized with message deliveries. While polling its ports in apolling cycle, if a port does not have a message already delivered toit, then the cell skips that port and polls its next port. Ports thatare skipped may receive new messages during the execution cycle. Portswhose pending messages were missed in one polling cycle will be sensedand included in the sortedPortsList in the next polling cycle. Thus,ports may not be serviced in the same order in which messages weredelivered to them. However, no input message would ever be missed by thecell, unless the cell was prematurely terminated or there were deadlocksin the application system. Thus, every transaction is completed undernormal operating conditions. This is an important requirement inTICC™-Ppde.

Other Modalities of Port Servicing: It is possible that a cell executesp:tip() immediately after it senses a pending message at port p, thusskipping the sorting cycle for that port. It is also possible to havesynchronous computations of the following kind: a cell waits at its portuntil a message is received (or until the port is ready); responds tothe message when it arrives (or writes and sends a new message, whenport becomes ready) and then only proceeds to poll its next port. Suchsynchronous computations are specified by using guards of the form,C.p:<guard>?()* in TIPs. The ‘*’ indicates the need to repeatedlyevaluate the guard until it becomes true. Starred guards are calledsynchronous guards.

An outline of computational facilities in TICC™-Ppde that supportgeneral parallel computations is presented in Sections and 3 and 4. Moredetails are presented in Section 5. Examples of TICC™-Ppdeimplementations are presented in Section 2 and examples withALLEOP-proofs are presented in Section 6. In Section 2, we use thesimple networks in FIGS. 1 through 4 to present two simple examplestaken from [Maggie & Kramer, 13]. The first example in Section 2 is usedto introduce ALLEOPs generated by the system from implementationspecifications, traces and causalnet derived from ALLEOPs and the roleplayed by SMS at run time. This example also illustrate concurrency,automatic coordination and temporal synchronization performed byTICC™-Networks, with no need to use monitors [Hoare, 12] or semaphores[Dijkshtra, 23,24]. The second example introduces the concept ofencapsulation in TICC™-Ppde and illustrates use of non-deterministicguards.

2. Simple Examples

Implementation specification in each example consists of theTICC™-network, TIPs for the various ports, CIPs for cells, and a pollingcycle for each cell. The polling cycle specifies the order in whichports are polled in a cell. The TICC™-network is an abstraction ofmessage exchanges, synchronization and coordination that occur incomputations. It specifies the control structure of parallelcomputations. No proofs are presented for the examples in this section;examples with ALLEOP-proofs are presented in section 6.

2.1. Bill and Ben Example: ALLEOPs, Traces and Causalnets

We begin with a simple game from [Magee & Kramer, 13]. FSP model of thegame, as it is given in [Magee & Kramer, 13] is:

||BILL_BEN = BILL || BEN; BILL= play→ meet→ BILL; BEN= work→ meet→ BEN;    (2.1)Synchronization in the conventional sense [12,13] is supposed to occuron the action term ‘meet’. TICC™-Ppde implementation of the game ispresented here. We show the ALLEOPs models derived from implementationspecifications, traces derived from ALLEOPs and the causalnet that SMSproduces. All derivations are done automatically by the system. ALLEOPmodels are models of implementations derived automatically fromimplementation specifications. They are not models of intended designsof a system as FSP models are in [Magee & Kramer, 13]. Thus, ALLEOPmodels are more complicated than FSP models, but in a sense theirstructures are similar to FSP structures.

The TICC™-network is shown in FIG. 5. Every TICC™-network has at leastone environment cell, E; also at times called the configurator cell. Itis used to configure the network and start operations. When theTICC™-GUI (Graphical User Interface) screen is opened it comes with Einstalled in it. Application programmer should have already defined thecell subclass, E, and other cell subclasses needed for the applicationbefore opening the TICC™-GUI. E, is activated by user by clicking on itsimage on GUI screen, and sending an interrupt signal to itsinterruptPort, E.i. E is used to install all other cells and allpathways in the TICC™-network. All the installed cells and pathwaysappear on the TICC™-GUI screen, and the resultant picture, after userperformed repositioning of images, looks like the one shown in FIG. 5.Once this is done, application is started by clicking on E and selectingthe ‘start’ command from a drop down menu. In response, E broadcasts aninterrupt signal to the interruptPorts of cells in the network, via itsport E.g1. This activates the cells.

In the following we use abbreviations, ‘Be’ for ‘Ben’, ‘Bi’ for ‘Bill’,‘Me’ for ‘Meeting’, and ‘B’ for ‘Ben and Bill’. [Be.f, Bi.f]=B.f and[Be.g, Bi.g]=B.g are port-groups. Ben and Bill both receive synchronizedsignals and send out coordinated signals through these port-groups:Agents a1 and a2 in FIG. 5 perform synchronization and coordination, asdiscussed in Section 1.3.2. The CIP of cell E is shown below:

E:CIP( ) Definition: void E::CIP( ){  initialize?( ){ init( ); E.g1:s(); E.i:s( );      stopPolling=initialize = false;}  while (

stopPolling){  (E.g:pR?( ) & E:readyToStart?( )*){ g:s( ); g:mR?( )*{ }}   E.i:mR?( ){ E.g1:s( ); E.g1:mR?( )*{ E.i:s( );   stopPolling=true;}} prepareToTerminate( ); }                (2.2)

The above CIP specifies the following operations: The first interruptsignal sent by user to the interruptPort E.i activates E and causes itto perform initialization defined in init (), which installs all cellsand pathways needed for the application. After this, E sends aninterrupt signal to the interruptPorts of cells in the game via its portg1. This activates the cells in the network in FIG. 5. Once activated, Ereplies to the interrupt signal that started it, initializes itsvariables, and then proceeds to execute its while-loop. In thewhile-loop it first polls its generalPort E.g. If port E.g is ready tosend out a signal and E is ready to start the game, E.g sends a signalto [Be.f, Bi.f]=B.f. This starts the game. Having started the game, Ewaits at its port E.g to receive end of game signal.

After receiving end of game signal, E polls its interruptPort E.i. If Esenses an interrupt signal then it begins to terminate its operations.This will be the second interrupt signal received by E from user. Thefirst one started it. Before terminating, E broadcasts an interruptsignal to all other cells, via its port g1. This would be the secondinterrupt signal broadcast by E. The first one started the cells. Eachcell that receives the second interrupt signal sends back a response andthen terminates itself. E terminates only after receiving thecoordinated response earlier, from all the cells to the interrupt signalit broadcast, to them. This coordinated response is forwarded to E byagent a3 in FIG. 5. This, with minor variations, is the generalstart/stop process used in all applications.

If there is no interrupt signal at E.i then E may repeat its pollingcycle, as shown in (2.2) and (2.7). Other cells in FIG. 5 have similarCIPs. Notice, the TIP at port E.g in (2.2) has another TIP, g:mR?()*{ },embedded in it whose tip-body is empty. But, in general tip-bodies ofembedded TIPs need not be empty. For example, in TIPs (2.4) and (2.5)below, TIP-bodies of embedded TIPs are not empty. Multiple suchembeddings may occur in a TIP. We have omitted the start/stop processesand interruptPort polling and servicing in the following discussions.

TIPs: All TIPs have the general structure, <TIP-guard>{<TIP-body>}. E.g:TIP( ):(E.g:pR?( )& E:readyToStart?( )*)           {E.g:s();E.g:mR( )*{ }}         (2.3)  Bi.f:TIP( ): Bi.f:mR?( ){Bi.f:play();Bi.g:s( );          Bi.g:mR?( )*{Bi.f:s( );}}          (2.4) Be.f:TIP( ): Be.f:mR?( ){Be.f:work( );Be.g:s( );          Be.g:mR?()*{Be.f:s( );}}         (2.5)  Me.f:TIP( ): Me.f:mR?( )*{Me.f:meet( ).s();}       (2.6)When Bill and Ben sense the signal sent by E they begin to do theirrespective things, play and work, as shown in (2.4) and (2.5). Afterfinishing whatever they did, each of them sends a signal to Me.f viatheir respective ports Bi.g and Be.g. Of course, they do not synchronizethe time at which they send signals. Agent a2 waits until it hasreceived signals from both Bi.g and Be.g and then sends a coordinatedsignal to Me.f. Thus Meeting always begins only when both Bill and Benare ready for it. When meeting is over, Me.f sends synchronized signalsto [Bi.g, Be.g]=B.g via agent a2 (see FIG. 5). When Bill and Ben receivethis signal they both send a coordinated end of game signal back to E.gvia a1. At this point, E may start the next iteration of the game, ifgaming is not terminated by an interrupt signal at its port E.i.

What is called synchronization in the FSP framework of [Magee & Kramer,13] is called coordination in TICC™-Ppde. Synchronization in TICC™-Ppdealways refers to temporal synchronization of events that occur inparallel. In this example, temporal synchronization occurs when signalfrom E.g is delivered to [Bi.f, Be.f]=B.f by agent a1, and when signalfrom Me.f is delivered to [Bi.g, Be.g]=B.g by agent a2.

POLLING CYCLES: //InterruptPort pollings have been ignored here.

E:Polling()=[E.g:pR?()→E:Polling()]  (2.7)

Be:Polling()=[Be.f:mR?()→Be:Polling()]  (2.8)

Bi:Polling()=[Bi.f:mR?()→Bi:Polling()]  (2.9)

Me:Polling()=[Me.f:mR?()*→Me:Polling()]  (2.10)

Polling is recursive because of the while-loop in CIPs (see (2.2)). Thiscompletes the design of the Bill-Ben game. When refinements for E:readyToStart(), Bi.f:play(), Be.f:work() and Me.f:meet() are completedthe implementation of the Bill-Ben game will be complete. Computationsperformed by specifications given so far, are characterized by thefollowing ALLEOPs.

2.1.1. ALLEOPs of BILL-BEN Game

Read ‘→’ in the following as ‘causes’ and ‘→’ as ‘immediately causes’.These are called causal connectives. They are defined in Section 5.ALLEOPs combine information in TIPs, TICC™-network and polling cycles.All ALLEOPs begin with “□[”, but we often omit the “□” symbol but itshould always be assumed to be present; the symbol be read as “always”,Five simple transformations occur when ALLEOPs are derived from TIPs:(i) “;” is replaced by “→”; (ii) “;} . . . }” is replaced by “} . . .}→” if ALLEOPs continues after the last right chain bracket, else it isreplaced by “;} . . . }]”. Similarly, “] . . . ]” and “) . . . )” isreplaced by “] . . . ]→” and “) . . . )→”, respectively, if ALLEOPscontinue, else by “] . . . ]” and “) . . . )]”. (iii) signal sendingactions caused by evaluation of p:s(), at ports p that appear in TIPsare replaced by their expansions in terms of signal sending anddelivering events with associated time-maps, as described below; (iv)also parallel activations caused by signal deliveries are specified, asdescribed below; and (v) each signal sensing action, p:mR?() (orp:mR?()*) is given the signal delivery event that is sensed by it, asits argument.

The port-ALLEOPs described below illustrate these transformations. Eachport-ALLEOP

has two components: ALLEOP-guard() and ALLEOP-body (), with thestructure, ALLEOP-guard () {ALLEOP-body ()}: ALLEOP-body () is invokedonly if ALLEOP-guard() is true, else the body is skipped. Let us firstconsider the port-ALLEOP for port E.g. This is derived from E.g:TIP() in(2.3), the TICC™-network in FIG. 5 and the polling cycle in (2.7). It isshown in (2.11) and its interpretation follows thereafter.

E.g:ALLEOP( ) = □[E.g:ALLEOP-guard( ){E.g:ALLEOP-body}]E.g:ALLEOP-guard( )= [E.g:pR?( ) & E:readyToStart?( )*] E.g:ALLEOP-body() = [E.g^(S)[T(E.g,0)]       →((

Be.f^(D)

[T(E.g,1)] || →...→ Be.f:ALLEOP( ))         (

Bi.f^(D)

[T(E.g,1)] || →...→ Bi.f:ALLEOP( )))       •→ E.g:mR?(

E.g^(D)

[T(B.f,1)])*{ }       •→ E.g:ALLEOP( ))}]          (2.11)

Here, E.g:ALLEOP-guard() is identical to E.g:TIP-guard() appearing in(2.3). Communication statement, E.g:s(), appearing in TIP-body in (2.3)has been transformed to signal sending/delivering events that occur whenE.g:s() is executed: signal sending event is, E.g^(S)[T(E.g,0)] (^(S)for Send), and signal delivery events are,

Be.f^(D)

[T(E.g,1)] and

Bi.f^(D)

[T(E.g,1)] (^(D) for Delivery). The suffixes, T(E.g,0) and T(E.g,1)appearing in the signal sending and delivering events are the time-maps.As explained in Chapter 2, each time-map maps to an increasing sequenceof time-points. The angle brackets, ‘

. . .

’, appearing around the delivery events in (2.11) specify that the eventoccurrences were completed at time-points specified in the time-maps.Absence of such angle brackets around the sending event E.g^(s)indicates, the event started occurring at a time-point specified in thetime-map. Thus, the presence and absence of angle brackets around eventsdistinguish between starting and ending times of those events.

The two signal delivery events in (2.11), Be.f^(D) and Bi.f^(D), haveidentical time-maps T(E.g,1). This specifies that signal is deliveredsynchronously to both the ports [Be.f,Bi.f] at the same time-point inT(E.g,1). Different values of # in the time-maps, T(E.g,#) for #=0 and1, uniquely identify the two different sequences of time-pointsassociated with the same port E.g. Distinct communication events at thesame port, appearing in a CIP or TIP have distinct values of #associated with them. The, events E.g^(s), Be.f^(D) and Bi.f^(D) are allcaused by the evaluation of the protocol at port E.g. Details ofprotocol evaluations are not shown in ALLEOPs.

Sequences of time points associated with time-maps are interpreted asfollows: The sequence, T(E.g,0)=(t₀, t₁, . . . , t_(n−1)), [t₀<t₁< . . .<t_(n−1)] represents the time points at which E started the i^(th)iteration of the game for 0≦i<n, by sending out a signal via E.g to theport-group B.f=[Be.f, Bi.f], and the sequence, T(E.g,1)=(t₀′, t₁′, . . ., t_(n−1)′), t_(i)<t_(i)′<t_(i+1), 0≦i≦n−1, represents the correspondingtime points at which signal deliveries to the ports in B.f occurred. For(0≦i<n) the time point t_(i) in T(E.g,0) corresponds to the time pointt_(i)′ in T(E.g,1), in the sense that signal sending that started attime t_(i) ended with the completion of the delivery event at timet_(i)′ and the two sequences mesh into a totally ordered chain,[t₀<t₀′<t₁<t₁′<t₂<t₂′< . . . <t_(n−1)<t_(n−1)′].

The delivery events cause parallel activations of other ALLEOPs. Thesymbol, ‘∥’, appearing in the delivery events in (2.11) specifies thatsignals activate the ALLEOPs Be.f:ALLEOP() and Bi.f:ALLEOP() inparallel. We refer to this as “parallel activation”, even if only oneother ALLEOP is activated by signal transmission, because the activatedcell works in parallel with activating cell. The ellipse, → . . . →,accompanying ‘∥’ indicates that activation may not happen immediatelyafter signal delivery. Ben and Bill might have been doing something elseat the time of signal delivery, instead of listening to the deliveredsignal. However, eventually they come around to sense the signal andrespond to it.

Finally, the argument “

(E.g^(D))

[T(B.f,1)]” appearing in “E.g:mR?(<E.g^(D)>[T(B.f,1)])*”, in (2.11)identifies the signal delivery event that is sensed by E.g:mR?()*. It isthe signal delivered back to E.g by the ports [Be.f, Bi.f]=B.f. Receiptof this signal indicates to E that the game started by E by sending asignal via E.g had terminated. The synchronous signal sensing operationE.g:mR?()* in (2.11) specifies, the cell E waits at port E.g to receivethis termination signal. The sensing action, E.g:pR?() in (2.11) is notgiven any argument, since in this case, it only tests the state of portE.g for readiness to send out a signal; it does not test for a deliveredsignal. The delivered signal was already tested by E.g:mR?()* in (2.11).If p:pR?() is used in a TIP to sense a delivered signal, then anargument will be provided for it.

System supplies arguments to signal sensing operations in ALLEOP-guards,at the time parallel activations are specified. There are no parallelactivations associated with E.g:pR?() in any of the ALLEOPs (2.11)through (2.14). Thus E.g:pR?() in (2.11) does not have an argument.However, (2.12) and (2.13) specify parallel activations for E.g:mR(){ }and thus E.g:mR( . . . )* in (2.11) has an argument. Other ALLEOPs givenbelow are similarly derived from their respective TIPs:

//Derived from Be.f:TIP( ) in (2.4), the network in Figure 5 and pollingcycle (2.8). Be.f:ALLEOP( )= □[Be.f:ALLEOP-guard( ){Be.f:ALLEOP-body()}] Be.f:ALLEOP-guard( )= [Be.f:mR?(

Be.f^(D)

[T(E.g,1)])] Be.f:ALLEOP-body( ) = [Be.f:work( )•→ Be.g^(S)[T(Be.g,0)]      →(

Me.f^(D)

[t(B.g,1)] || Me.f:ALLEOP(...))       •→ Be.g:mR?(

Be.g^(D)

[T(Me.f,1)])*{                Be.f^(S)[t(Be.f,0)]}       → (

E.g^(D)

[T(B.f,1)]          || E.g:mR(

E.g^(D)

[T(B.f,1)])*{ })}      → Be.f:ALLEOP( )]               (2.12)Notice in (2.12), the time-map in signal sending eventBe.g^(s)[t(Be.g,0)] does not refer to the port-group B=[Be.g, Bi.g],however the time-map in the signal delivery event

Me.f^(D)

[t(B.g,1)] does refer to B. This is because Ben does not coordinate withBill the time he sends out the signal via Be.g, but agent a2 (see FIG.5) sends a coordinated signal causing the delivery event

Me.f^(D)

[t(B.g,1)] to occur. Similar timing specifications appear in eventsBe.f^(s)[T(Be.f,0)] and

E.g^(D)

[T(B.f,1)].

//Derived from Bi.f:TIP( ) in (2.5), the network in Figure 5 and pollingcycle (2.9) Bi.f:ALLEOP( ) = □[Bi.f:ALLEOP-guard( ){Bi.f:ALLEOP-body()}] Bi.f:ALLEOP-guard( )= [Bi.f:mR?(

[Bi.f^(D)

 [T(E.g,1)])] Bi.f:ALLEOP-body( ) =   [Bi.f:play( )•→Bi.g^(S)[T(Bi.g,0)]    → (

Me.f^(D)

 [t(B.g,1)] || Me.f:ALLEOP(...))    •→Bi.g:mR?(Bi.g^(D)[T(Me.f,1)])*{Bi.f^(S)[T(Be.f,0)]}     → (

E.g^(D)

 [T(B.f,1)] || E.g:mR((

E.g^(D)

 [T(B.f,1)])*{ })}     → Bi.f:ALLEOP( )] (2.13)

Identical time-maps appearing in distinct port-ALLEOPs indicate thatevents associated with those time-maps occur at the same time in thedifferent ALLEOPs. Thus

Me.f^(D)

[T(B.g,1)] in ALLEOPs (2.12), (2.13) and (2.14) indicate that the samedelivery event is being referred to in the three ALLEOPs. Similarly,

E.g^(D)

[T(B.f,1)] in ALLEOPs (2.11), (2.12) and (2.13) refer to the samedelivery event. Notice, there are no ellipses, ‘→ . . . →’, followingthe parallel activations in (2.12), (2.13) and (2.14). This is becausethe signal receiving cells are waiting at their respective ports for thesignals; so they sense the delivered signals immediately.

//Derived from Bi.f:TIP( ) in (2.6), the network in Figure 5 and pollingcycle (2.10) Me.f:ALLEOP( ) = □[Me.f:ALLEOP-guard( ){Me.f:ALLEOP-body()}] Me.f:ALLEOP-guard( )= [Me.f:mR?(

Me.f^(D)

 [T(B.g,1)])*] Me.f:ALLEOP-body( ) =  [Me.f:meet( ) •→Me.f^(S)[T(Me.f,0)]   → ((

Be.g^(D)

 [T(Me.f,1)]||Be.g:mR(Be.g^(D)[T(Me.f,1)])*{•→...•→})   → ((

Bi.g^(D)

 [T(Me.f,1)]||Bi.g:mR(Bi.g^(D)[T(Me.f,1){•→...•→})*))   •→ Me.f:ALLEOP()] (2.14)

Rules for deriving ALLEOPs from TIPs are simple. ALLEOP structures looksimilar to FSP structures. But, as the reader can see, there are severaldifferences. ALLEOPs represent events and causal links. FSPs representstates and transitions. We will later see a relationship between ALLEOPsand FSPs. It should be pointed out, actions specified in ALLEOPs, likethe actions Be.f:work(), Bi.f:play() and Me.f:meet(), may in generalcause branching causal sequences to occur in the ALLEOP. There are twokinds of branchings: One is choice branching, where one alternative froma finite set of causal sequences is chosen to run at run-time byevaluating choice conditions associated with the causal sequences andselecting the first one that evaluated to true. We use symbol, ‘|’, toseparate out the choice alternates (see (4.14)). No choice branchesoccur in the above ALLEOPs. The other kind of branching, is multipleparallel branching (forks), like the ones in ALLEOPs (2.11) and (2.14)that occur as a result of communications.

-   -   Partial Ordering of Time-Maps: The various time-maps and their        partial ordering in this example are,

T(E.g,0), signal is sent to Bi.f and Be.f start game<T(E.g,1), signal isdelivered to Bi.f and Be.f<(T(Be.g,0), T(Bi.g,0)) Bi.g and Be.g sendstart meeting signals to Me.f<T(B.g,1), start meeting signal isdelivered to Me.f by agent a2<T(Me.f,0), end of meeting signal is sentto Bi.g and Be.g<T(Me.f,1), end of meeting signal is delivered to Bi.gand Be.g<(T(Be.f,0), T(Bi.f,0)), end of game signal to E.g<T(B.f,1)],end of game signal is delivered to E.g by agent a1  (2.15)

Incomparable Pairs of Time-Maps:

(T(Be.g,0), T(Bi.g,0))≦T(B.g,0),a2 sends coordinated signal toMe.f(T(Be.f,0), T(Bi.f,0))≦T(B.f,0), a1 sends coordinated signal toE.g  (2.16)

It is possible that the pairs of incomparable time-maps in (2.16)intersect with each other, i.e., T(Be.g,0)∩t(Bi.g,0)≠φ andT(Be.f,0)∩T(Bi.f,0)≠φ. This implies that at times both Ben and Billcould send out signals simultaneously, just by chance. The combinedALLEOP is,

BILL_BEN:ALLEOP( )=   □[∃(<partial-ordering-of-time-maps>)    (E.g:ALLEOP( )||Be.f:ALLEOP(...)||Bi.f:ALLEOP(...)||    Me.f:ALLEOP(...))     •→ BILL_BEN:ALLEOP( )] (2.17)Here, parallel operations of cells are constrained by the partialordering in (2.15) and (2.16). This restriction is automatically imposedby the network structure and signal exchange timings. No scheduling isinvolved. The port-ALLEOPs defined in statements (2.11) through (2.14)are the models of computations performed by the application. TICC™-Ppdecan generate series/parallel combinations of port-ALLEOPs that areconsistent with TICC™-network and polling specifications, in order togenerate the complete ALLEOPs model of an implementation. Any propertywe prove using the ALLEOPs models will be a valid property of theimplementation, not just a property of an intended design. All ALLEOPsbegin with the universal temporal operator, □. We will omit thisoperator in ALLEOP descriptions. It should always be assumed to bepresent.

2.1.2. ALLEOP of a CIP

Let us now write the ALLEOP for the CIP in (2.2): Here we havepostulated a port called User.g, which sends interrupt signals to E.1.User is not shown in FIG. 5!

E:CIP-ALLEOP( ) = [E:CIP-ALLEOP-init( )•→ E:CIP-ALLEOP-body]E:CIP-ALLEOP-init( ) =   [E:initialize?( ){ init( ) •→ E.i^(S)[T(E.g,2)]        → (

User.g^(D)

[T(E.g,3) ||         →...→ User.g:ALLEOP( ))         •→ stopPolling =false         •→ initialize = false] E:CIP-ALLEOP-body( ) =   [(

E:stopPolling?( ){(E.g:ALLEOP( ) •→ E.i:ALLEOP( )           •→E:CIP-ALLEOP-body( )} |     E:stopPolling?( ){prepareToTerminate()})]    (2.18)Notice, time-maps T(E.g,2) and T(E.g,3) are used in (2.18). This isbecause T(E.g,0) and T(E.g,1) have been already used in E.g:ALLEOP()(see (2.11)), and E.g:ALLEOP() appears in E:CIP-ALLEOP-body() in (2.18).Here, E:initialize?()=E.initialize; similarly,

E:stopPolling?()=

E.stopPolling. Every Boolean attribute of an object has a predicate ofthis kind or a Boolean combination of predicates of this kind. In(2.18), ports of cell E are not sorted before their TIP-bodies areexecuted.

The CIP-ALLEOP of the kind shown in (1.1) for a CIP, the ports aresorted before their TIP-bodies are executed, as shown below In (2.19).Following assumptions have been made in (2.19): port X.g sends theinterrupt signal that activates the Cell; and poll&SortPorts() methodappearing in (1.1) has been split into two components; polling andsorting. In the arguments appearing in Cell:sortInto( . . . ) in (2.19),Cell.ports is a vector of ports attached to Cell, Cell.sortedPortsList(referred to by Cell.spL) is another vector, which will contain thesorted ports with pending messages, and the argument sortR is thesorting relation. All are defined in the Cell class.

Cell:CIP-ALLEOP( ) = [Cell:CIP-ALLEOP-init( ) •→       Cell:CIP-ALLEOP-body] Cell:CIP-ALLEOP-init( )=[Cell:init-ALLEOP() •→ stopPolling=false         •→ initialize=false         •→Cell.i:pR?( ){Cell.i^(S)[t(Cell.i,0)]           →(

X.g^(D)

[t(Cell.i,1)]             || →...→ X.g:ALLEOP( ))}]Cell:CIP-ALLEOP-body( ) = //in the following read “spL” as“sortedPortsList”.   [(

Cell:stopPolling?( ){ Cell.i:ALLEOP( ) •→ Cell.spL:clear( )     •→ ∀(j)(0≦j<Cell.ports:size( )){       Cell.ports[j]:mR?( ){        Cell:sortInto(Cell.ports[j],Cell.spL,sortR)}}     •→ ∀(j)(0≦j<Cell.spL:size( )){Cell.spL[j]:ALLEOP-body( )}     •→Cell:CIP-ALLEOP-body( )} |     Cell:stopPolling?( ){prepareToTerminate()})]  (2.19)Here, “∀(j) (0≦j<Cell.ports:size())” and “∀(j) (0≦j<Cell.spL:size())”are used as enumerators of indices in the specified range; actions intheir, respective, scopes are applied to each enumerated index.

2.1.3. Traces

Differences between traces and ALLEOPs are the following: (i) Tracespostulate virtual time points (hereafter simply referred to astime-points), at which events and evaluations begin and/or end. (ii)Traces associate precondition and postcondition with actions when theyare known. Characterization of an action, A(), has the form,

□[∃(t₀ < t₁){

precondition?( )

(t₀)}[•→ A( ) (t₀)]   {

A.output:C?( ) & postcondition?( )

(t₁) &   (t₁-t₀ ≦ τ_(max)(A)}] (2.20)where A is either a pthread, a protocol or a program statement;Σ_(max)(A) is the maximum time it might take to complete execution ofA(), → is the action evaluation symbol, A() begins execution at thesame time t₀ when the precondition?() becomes true and execution of A()is completed at time t₁ when postcondition?() becomes true. Such actioncharacterizations are developed interactively by users with assistancefrom the system. (iii) Traces also specify characterizations of inputmessages, if any, in the precondition. A.output:C?() may characterizethe output message, if any. Traces may contain branches specifyingalternates and parallel forks if their corresponding ALLEOPs containthem. We omit the ‘□’ symbol in trace statements; it is assumed to bepresent.

When system derives the trace for a port-ALLEOP it simply postulatesdistinct virtual-time points for distinct events in port-ALLEOPs, takingcare identical virtual time points are associated with identicaltime-maps in the port-ALLEOPs. This captures synchronization andcoordination of events occurring in different port-ALLEOPs. Ordering oftime points with in a trace is dictated by the order in which eventsoccur in the port-ALLEOP. Three assumptions are made in this ordering:(i) Successive actions linked by → will occur immediately one after theother, the action at the end of the link starting at the same time asthe action at the beginning of the link terminates. (ii) Every actiontakes a finite amount of non-zero time to complete execution with aknown upper bound, (iii) If a cell is waiting for a signal at a port atthe time signal is delivered to that port, then the delivered signal issensed immediately at the same time as the signal delivery time,otherwise signal sensing may occur sometime after signal delivery. (iv)When a cell sends out a signal through a port C.p at virtual-time, Cp.t,if C.p belonged to a port-group, pG, then the system knows that theagent that receives signals sent by the ports in pG would dispatch acoordinated signal only after receiving signals from all the ports inpG. Let us say, this dispatch occurs at time pG.t. In this case, thesystem introduces the ordering, Cp.t≦pG.t, into the port-trace for everyport C.p in pG.

Traces for the port-ALLEOPs in (2.11) through (2.14) are presentedbelow, together with their interpretations. Traces for the Ben-Billsolution contain parallel forks. In the trace (2.21) below thatcorresponds to ALLEOP in (2.11), the expression ‘( . . . ∥ . . . ∥ . . .)’ enclosed in parentheses describes a parallel fork. There are noactions appearing in this trace. The actions, play(), work() and meet()appear in traces (2.22) through (2.24). But these actions do not havepre/post-conditions defined for them. Therefore, none appear in traces.An example of a trace with pre/post-conditions and message conditionsappears in (2.26).

In each trace the trace-body is invoked for analysis during a proofconstruction process only if the trace-guard is to true, else it isskipped. The trace E.g: trace (Eg.t₀) at port E.g, corresponding toALLEOP, E.g:ALLEOP() in (2.11), is shown below:

□[∃(Eg.t₀ < Eg.t₁ = Bf.t₀ < Eg.t₂ < Eg.t₃ = Bf.t₁)] E.g:trace(Eg.t₀) =  {•→ E.g:trace-guard(Eg.t₀)}[•→ E.g:trace-body(Eg.t₁)]E.g:trace-guard(Eg.t₀) =   [

(E.g:pR( ) & E:readyToStart( )*) (Eg.t₀)

(Eg.t₁)] E.g:trace-body(Eg.t₁) =   [[•→ E.g^(S)(Eg.t₁∈t(E.g,0))]      (([

→ Be.f^(D)

(Eg.t₂∈T(E.g,1))] || [→       Be.f:trace(Eg.t₁)])        ([

→ Bi.f^(D)

(Eg.t₂∈T(E.g,1))] || [→        Bi.f:trace(Eg.t₁)]))     {

E.g:mR(

E.g^(D)

(Eg.t₃ ∈ T(B.f,1)))*

(Eg.t₃)}           [•→ E.g:trace(Eg.t₃)]] (2.21)

Expression “

(E.g:pR()&E:readyToStart()*)(Eg.t₀)

(Eg.t₁)” in E.g:trace-guard(Eg.t₀) in (2.21) asserts that evaluation ofthe condition, (E.g:pR() & E:readyToStart()*), begins at time Eg.t₀ andterminates at time Eg.t₁. Assignment of the same time-point, Eg.t₂, tothe two events,

→Be.f^(D)

and

→Bi.f^(D)

in (2.21) indicates that signal deliveries to ports Be.f and Bi.f weremade simultaneously at the same time-point. Specification,“[→E.g^(s)(Eg.t₁εT(E.g,0))]” in E.g: trace-body, without angle bracketsaround, “→E.g^(s)”, asserts that evaluation of action that caused eventE.g^(s) to occur, started at time Eg.t₁εT(E.g,0). Notice, the startingtime of “→E.g^(s)” is the same as the ending time of “

(E.g:pR()&E:readyToStart()*)(Eg.t₀)

(Eg.t₁)”. Ending time of “→E.g^(s)” is not specified. Interpretationsof timings associated with other statements in (2.21) are the same as inALLEOPs, with the difference that virtual time-points are postulated ineach case. Just as time-maps represent sequences of time points, eachvirtual-time point also represents a sequence of time points. Thus in(2.21), Eg.t₁εT(E.g,0) is a sequence of time points at which E startedthe Bill-Ben game. Other port-traces associated with the ALLEOPs in theBill-Ben game are shown below.

Bi.f:trace (Bif.t₀)=   {Bi.f:trace-guard(Bif.t₀)}[•→Bi.f:trace-body(Bif.t₁)] [∃(Eg.t₁ = Big.t₀ ≦ Bif.t₁ < Big.t₀ ≦ Bg.t₀ <Bg.t₁ = Mef.t₀ <   Big.t₁ = Mef.t₃ = Big.t₁ < Bif.t₂ ≦ Bf.t₀ < Bf.t₁ =Eg.t₃) Bi.f:trace-guard (Bif.t₀) =     {

Bi.f:mR?(

Bi.f^(D)

(Bif.t₀∈T(E.g,1)))

(Bif.t₁)} Bi.f:trace-body(Bif.t₁) =     [[•→ Bi.f:play( ) (Bif.t₁)]     [•→ Bi.g^(S)(Big.t₀∈T(Bi.g,0) ≦ Bg.t₀∈T(B.g,0))]       ([

→ Me.f^(D)

(Bg.t₁∈T(B.g,1))] || [•→ Me.f:trace(Bg.t₁)])      [

Bi.g:mR?(<Bi.g^(D)

(Big.t₁∈T(Me.f,1)))*

(Big.t₁)}       ([•→ Bi.f^(S)(Bif.t₂ ≦ Bf.t₀∈T(B.f,0))]         ([

•→ E.g^(D)

(Bf.t₁∈T(B.f,1))]          ||{E:g:mR(

•→E.g^(D)

(Bf.t₁))*}[ ][•→ E.g:trace(Bf.t₁)]))      [•→ Bi.f:trace(Bf.t₁)]]](2.22) Be.f:trace(Bef.t₀) =   {Be.f:trace-guard(Bef.t₀)}[•→Bi.f:trace-body(Bef.t₁)] [∃(Eg.t₁ = Bef.t₀ ≦ Bef.t₁ < Beg.t₀ ≦ Bg.t₀ <Bg.t₁ = Mef.t₀ <   Beg.t₁ = Mef.t₃ = Beg.t₁ < Bef.t₂ ≦ Bf.t₀ < Bf.t₁ =Eg.t₃) Be.f:trace-guard(Bef.t₀) =     {

Be.f:mR?(

Be.f^(D)

(Bef.t₀∈T(E.g,1)))

(Bef.t₁)} Be.f:trace-body(Bef.t₁) =     [([•→ Be.f:work( )(Bef.t₁)]     [•→ Be.g^(S)(Beg.t₀∈T(Be.g,0) ≦ Bg.t₀∈T(B.g,0))]         ([

→ Me.f^(D)

(Bg.t₁∈T(B.g,1))] || [•→ Me.f:trace(Bg.t₁)])           {

Be.g:mR?(

Be.g^(D)

(Beg.t₁∈T(Me.f,1)))*

(Beg.t₁)}         ([•→ Be.f^(S)(Bef.t₂ ≦ Bf.t₀∈t(B.f,0))]             ([

•→ E.g^(D)

(Bf.t₁∈T(B.f,1))]              ||{E.g:mR(

•→E.g^(D)

(Bf.t₁))*}[•→ E.g:trace(Bf.t₁)]))       [•→ Be.f:trace(Bf.t₁)]]] (2.23)Me.f:trace(Mef.t₀) =      {Me.f:trace-guard(Mef.t₀)}[•→Me.f:trace-body(Mef.t₁)] [∃(Mef.t₀ = Bg.t₃ = Mef.t₁ < Mef.t₂ < Mef.t₃ =Beg.t₁ = Big.t₁)  Me.f:trace-guard(Mef.t₀) =     {

Me.f:mR?( )(

Me.f^(D)

(Mef.t₀∈T(B.g,1)))*

(Mef.t₁)}  Me.f:trace-body(Mef.t₁) =     [([•→ Me.f:meet( )(Mef.t₁)]      [•→ Me.f^(S)(Mef.t₂∈T(Me.f,0))]         (([

→ Be.g^(D)

(Mef.t₃∈T(Me.f,1))]           || {

Be.g:mR?(

Be.g^(D)

(Mef.t₃))*

(Mef.t₃))} •→...•→ )          ([

→ Bi.g^(D)

(Mef.t₃∈T(Me.f,1))]           || {

Bi.g:mR?(

Bi.g^(D)

(Mef.t₃))*

(Mef.t₃))} •→...•→ )))        [•→ Me.f:trace(Mef.t₃)]]] (2.24)

Incomparable Time Points:

(Bif.t₁,Bef.t₁)(Bif.t₂,Bef.t₂)(Beg.t₀,Big.t₀)  (2.25)

The existential declarations in the first lines of (2.22) and (2.23)specify that Bif.t₀=Eg.t₁<Bif.t₁ and Bef.t₀=Eg.t₁<Bef.t₁ indicating thatsignals are delivered to ports Bi.f and Be.f synchronously at virtualtime Eg.t₁ but the delivered signals are not sensed synchronously. Theyare sensed at the incomparable time points, Bif.t₁ and Bef.t₁.Similarly, when Bill and Ben send out signals to E.g at virtual times,Bif.t₂ and Bef.t₂, respectively, they do not coordinate the times atwhich they send the signals out. However, when both signals are receivedby agent a1 at time Bf.t₀, a1 dispatches a coordinated signal to E.g.This signal dispatch time is always  the signal sending times. Hencethe declarations, Bif.t₂≦Bf.t₀ and Bef.t₂≦Bf.t₀ appear in (2.22) and(2.23). Similarly, (Beg.t₀, Big.t₀)≦Bg.t₀, is coordinated by agent a2 attime Bg.t₀. Bill and Ben sense signals delivered to their ports Bi.g andBe.g immediately after signal delivery at time Bg.t₁, since they areboth waiting for the signals at the time signal is delivered.

Reader should be able to follow how time points that are identical toeach other in different port-traces are identified through theirmembership in time-maps. Equalities between virtual time points soidentified are introduced into the existential declarations on top ofeach trace. All time-points that occur in traces of ports in differentcells, that are not related to each other by equality or inequalityrelations are incomparable time points.

Once all traces have been generated, the system knows the virtual timepoints that appear in the time-maps specified in ALLEOPs and all virtualtime points that do not appear in any time-maps. The system then setstime points appearing in identical time-maps in different port-traces,equal to each other. This identifies all coordinated and synchronizedsignal deliveries. In the case of the trace in (2.21) the existentialdeclaration of time points at the top of the trace thus declares,Eg.t₃=Bf.t₁, where Eg.t₃ is the virtual time at which port E.g receivesthe signal delivered to it and Bf.t₁ is the time point at which agent a1delivered that signal (see FIG. 5). The delivered signal is here sensedimmediately, since E.g is waiting for the signal. This identifiescoordinated signal delivery to port E.g specified by the time-mapT(B,f,1) in the ALLEOPs (2.11), (2.12) and (2.13). Similarly in (2.22)and (2.23), Bef.t₀=Eg.t₁=Bif.t₀. This specifies synchronized signaldeliveries to ports [Be.f, Bi.f]=B.f. These identifications of virtualtime points are consistent with the partial ordering shown in (2.15).After setting up the relationships among virtual time points, the systemassigns the delivery event arguments to all signal sensing operations inthe traces, in a manner that is consistent with traces that areactivated by those events. Translating ALLEOPs to traces is notcomplicated if message characterizations and pre/post-conditionsassociated with actions are known; user assistance may be needed toacquire these.

Port-traces in this application use only signal sensing conditions. Insection 6.4 and Appendix III, traces contain a variety of conditions andbranching actions, with pre/post-conditions associated with actions.Each trace gives rise to its Event Characterization Table (ECT), whichis simply a reorganization of information in the trace in a tabular formthat is convenient for proof generation. We will see examples in Section6.

2.1.4. Trace of a CIP

Trace fragments of the CIP-ALLEOP (2.19) are presented below in (2.26),to illustrate how statements with ∀-enumerators are handled. The phrase,(p[i]

q[i]) appearing in (2.26) asserts that there is a pathway between theports p[i] and q[i]. Indices or items are enumerated by ∀-enumerators inan order. In the following, it is assumed, enumeration of an index i isfollowed by the enumeration of the index i+1, for 0≦i<n−1. TheALLEOP-statements with enumerators appearing in (2.19) are reproducedbelow, for convenience (read spL as sortedPortsList):

•→∀(i)(0≦i<Cell.ports:size( )){   Cell.ports[i]:mR?(){Cell:sortInto(Cell.ports[i],spL,sortR)} •→ ∀(j)(0≦j<Cell.spL:size()){spL[j]:ALLEOP-body( )}   (2.19a)The trace of above enumerator statements is given below:

 [∀(i)((0≦ i < (Cell.ports:size( )−1)   (∃(Cp[i].t_(i) < Cp[i].t_(i+1) =Cp[i+1]t_(i+1)) ∃(q[i].t₀ < Cp[i].t_(i) < q[i+1].t₀))//declarations ofvirtual time points used in the trace. ∀(i)(0 ≦ i < (Cell.spL:size( )−1)  ∃(i)(k)(sPL[i].t_(k)<sPL[i].t_(k+1)=sPL[i+1]t_(i+1)))//virtual timepoints declarations.  [∀(k)(0 ≦ k < Cell.ports:size( ))//Here ∀(k) is anenumerator for actions that follow.   ∃(Portsp[k],q[k])(p[k]=Cell.ports[k] & (q[k]

p[k]))   /* in the following q[k] is the port that delivers signal top[k]. Signal is delivered at time q[k] .t₀ and   sensing is completed attime Cp[k] .t_(k) */   {

p[k]:mR?(

p[k]^(D)

(q[k].t₀))

(Cp[k].t_(k))}    /*the following sorting action starts at the timesignal sensing is completed, namely Cp[k] .t_(k), and    ends at time,Cp[k] .t_(k+1); sortR is the sorting relation.*/    [

•→ Cell:sortInto(p[k],spL,sortR)(Cp[k].t_(k))

(Cp[k].t_(k+1))]   {((k=0)& spL[0] = p[0])

   (k>0 & spL[0] = p[k] & (p[k] sortR sortedPortsList[1]))

   (k>0 & ∃(j>0)(spL[j]=p[k] & (spL[j−1] sortR p[k]))}]  //spL[j]:trace-body( ) starts at time sPL[j] .t_(j) and ends at timesPL[j] .t_(j+1)  [{∀(j)(0≦j<Cell.spL:size( ))//Here also ∀ (j) is beingused as an enumerator    [

•→ spL[j]:trace-body( )(spL[j].t_(j))

(spL[j].t_(j+1))]]]  (2.26)

Features to be noticed in (2.26) are the following: (i) signal isdelivered to port p[k] at time q[k].t₀ and the delivered signal issensed at time Cp[k].t_(k). The sorting action, Cell:sortInto( . . . ),for index, k, starts immediately at the same time, Cp[k].t_(k). Thissorting action for index k terminates at Cp[k].t_(k+1), when sortingaction for the index (k+1) begins. This is declared in the timingspecifications on top, where the declaration,Cp[k].t_(k+1)=Cp[k+1].t_(k+1), appears. A similar timing structureappears for the other enumerator statement. (ii) Pre/post-conditions arepresented for the [

→Cell:sortInto(p[k],spL,sortR) (Cp[k].t_(k))

(Cp[k].t_(k+1))] action. Generating traces for the CIP-ALLEOP (2.19),using the above trace fragments should be quite straight forward.

2.1.5. Graphical Representations of ALLEOPs and Causalnets

Graphical representation of the ALLEOPs for this application is shown inFIG. 6A. It represents the series parallel composition of theport-ALLEOPs described in (2.11) through (2.14). Nodes that appear inthe ALLEOP graph in FIG. 6A are called event classes, since manyinstances of each node may occur when the application runs iteratively.Directed links between pairs of event classes represent causalrelationship between the event classes. Labels on the links in FIG. 6Amark conditions, which should hold true for those links to occur. Onlysignal sensing conditions appear here.

The causalnet produced by the SMS in a single run of the game, for theALLEOPs-graph in FIG. 6A, is shown in FIG. 6B. Each node in FIG. 6B isan instance of its corresponding ALLEOP node. Where as ALLEOPs showaction events for play(), work() and meet(), causalnets show only thecommunication events, which are instances of communication event classesthat appear in ALLEOPs and traces. Instead of the virtual time pointspostulated in traces the time instances associated with causalnet eventsare the time points in a global clock associated with the application.It is the time at which the events occurred in a run of thatapplication. FIG. 6C shows the causalnet when the game is repeatedseveral times. The causalnet preserves the temporal ordering shown inFIG. 6A, with the difference that the looping link in FIG. 6A isreplaced by iterations, as shown in FIG. 6C. It should be clear, justlike time-maps, virtual time points in traces also have sequences oftime instances associated with them.

The set of event nodes that appear in a causalnet is simply the set ofall communication events that occur in a run of an application andappear in the traces of the application, together with their respectivetimes of occurrence. If traces contained choice points, then not allevents that appear in traces will have corresponding events in thecausalnet; only the events selected at choice points will havecorresponding events in the causalnet. All pre/post-conditions, sensingof events and action events that appear in traces do not appear incausalnets. Thus causalnets are abstractions of trace fragments thatcorrespond to communication events that occurred in a run of anapplication. Nodes that receive synchronous input signals have identicalglobal time instances associated with them. Similarly nodes thatdispatch coordinated output signals through agents also have identicalglobal dispatch time instances associated with them. Each distinctvirtual time point associated with an event class in a trace correspondsto a distinct sequence of time instances associated with the instancesof that event class in the causalnet generated from that trace. Thus,the virtual time-point Eg.t₁ appearing in the phraseE.g^(s)(Eg.t₁εT(E.g,0)) in (2.21) represents the sequence of timepoints, T(E.g,0)=[t₀, t₇, t₁₅, . . . , t_(8n+7), . . . ] shown in FIG.6C.

Nodes are linked to each other in causalnet by directed links as shownin FIGS. 6B and 6C. The links specify partial ordering of the nodes.There are two kinds of links: (i) causal links, which specify orderingof events that occur during the execution of a TIP, and (ii) executionlinks, which specify ordering of different TIP executions, as they occurin cells during a run of the application. Partial ordering of eventinstances in a causalnet is the union of causal links and executionlinks. In FIG. 6C the links between successive iterations of the gameare execution links. All other links are causal links. In this case,each cell has only one TIP, since we have ignored interruptPortactivities. More execution links will appear in a causalnet if cellshave multiple generalPorts and functionPorts.

If the causal link, X→Y or X→Y, occurs in a port-ALLEOP and eventinstance, x(t) of X, occurs in the causalnet, then event instance Y(t+τ)of Y is bound to occur in the causalnet after a certain delay τ,τ_(max)(X/Y)≧τ>0, as per definition (5.27)(a) in Section 5.4. If thecausal link, X^(C(X,Y))→Y or X^(C(X,Y))→Y occurs in the graph of aport-ALLEOP with condition C (X,Y) associated with causal link, or thephrases, C(X,Y)?(){X→Y} or C(X,Y)?(){X→Y} in the textual description ofthe port-ALLEOP, then event instance Y(t+τ) of Y is bound to occur inthe causalnet after a certain delay τ, τ_(max)(X,Y)≧τ>0, only if thecondition C(X,Y) is true at time (t+τ). This is guaranteed because, asexplained in Section 5.5, (i) any pthread or protocol that is executedby a cell is uninterruptible, (ii) activation of the pthread andprotocol is automatic (not scheduled by any program that is external tothe cell) and (iii) progress is guaranteed unless, of course, there is asystem failure, deadlock or livelock (part of the system is deadlocked).In the general case, one has to prove freedom from deadlocks andlivelocks.

The Self-Monitoring System, SMS, may be set up to issue alerts any timethe causalnet of an application deviates from ALLEOPs. Also, one mayspecify alert situations by defining event patterns as regularexpressions of ALLEOP nodes. Thus, if event Y does not occur after aspecified upper bound, τ_(max)(X,Y), in X→Y and X→Y, then SMS willissue an error alert. If the event Y occurs after the specified upperbound for the delay, then SMS will issue an impending error alert. Undernormal operating conditions, every event in the ALLEOP in FIG. 6A isbound to occur, if its pre-conditions are satisfied, once the eventcorresponding to the bottom node occurs, else an alert will begenerated. Thus, in this case progress is guaranteed.

As discussed in Section 7, events in a causalnet are dynamicallyinstalled by specialized cells, called Event Builder cells (eb cells),in parallel with an application's operations, while the application isrunning and events are occurring in the application. Event patterns thatappear in a growing causalnet are recognized by Event Analyzer cells (eacells). If a pattern in an a priori specified alert condition occurs ina growing causalnet, then the ea cell associated with that pattern willgenerate an alert. SMS may be set up to notice any departure fromprogress specified in ALLEOPs and issue alerts. SMS may also be set upto influence ongoing computations in an application, based on patternsrecognized dynamically in a growing causalnet, by setting up pathwaysbetween selected generalPorts of ea cells and interruptPorts ofappropriate cells in an application, and defining TIPs for those ports.

2.1.6. Comments

Non-Determinism in TIP executions: TIP executions in distinct cells arenot synchronized with each other. Neither are they synchronized withsignal delivery events. A TIP at a port is executed only if there is adelivery signal at that port at the time the parent-cell of the portpolls that port; else the port is skipped. One cannot predict the orderin which signals arrive at different ports of a cell. Thus, the order inwhich a cell executes TIPs at its ports cannot be predicted. Therefore,one cannot predict when a cell will sense a signal delivered to one ofits ports and respond to it. Since a signal missed at a port in onepolling cycle is always caught in the next polling cycle, one can set abound on when a cell may respond to a signal, after the signal has beendelivered to a port: If Δ^(C) _(max) is the maximum time needed in apolling cycle of cell C to service all ports with pending messages, thenthis bound is <2Δ^(C) _(max). This is a source of non-determinism thatis intrinsic to TICC™-Ppde.

Sharing CPUs: The network shown in FIG. 5 requires at least three CPUsto run it. The environment E may suspend its operations and release itsCPU after sending signals to Bill and Ben. When Meeting receives signalfrom Bill and Ben it may get activated automatically in an availablefree CPU, and later when E receives signal from Bill and Ben it maysimilarly resume suspended operations in any available free CPU. Ingeneral, the number of CPUs needed to run a network is at least one plusthe maximum number of cells that run in parallel. The CPUs are switchedaround the cells that run intermittently, if cells have been programmedto suspend/resume their operations. It is not, however, desirable toswitch CPUs dynamically in TICC™-Ppde since CPU assignment to cells andactivation of assigned CPU are relatively expensive operations takinganywhere from 2.5 to 5 microseconds. This is done in TICC™-Ppde onlywhen dynamically growing TICC™-networks are encountered (Section 6.7,FIG. 18).

Progress: In the diagrams in FIG. 6, there is an implicit assumptionthat the pthreads, play(), work() and meet() are unconditional and areassumed to always terminate. With this assumption, the application doesnot have deadlocks or livelocks, and meeting synchronization occurs inall iterations of the game. We introduce formal proof methods in Section6. We will see situations in the Dining Philosophers example, whereprecautions are taken to guarantee that the implementation is free ofdeadlocks and livelocks, and the refinement structure of computationsplays a role in being able to prove this guarantee.

ALLEOPs and FSPs: As mentioned earlier, nodes in ALLEOPs and traces ofTIPs are event classes and links specify partial ordering, if loops inALLEOPs are removed. It may be noticed, if the looping link is removedin FIG. 6A, then the ALLEOPs graph is a lattice. This is a special case.As mentioned earlier, nodes and links in ALLEOPs graphs do not representstates and transitions. However, if the number of states in the statediagram of an application that is modeled by ALLEOPs is finite then theALLEOPs should be in some sense equivalent to an FSP. We refer to suchALLEOPs as finite-ALLEOPs. The set of all possible causal chains in afinite-ALLEOP should then be a regular set.

FSPs Viewed as Abstractions of Finite-ALLEOPs: Suppose in the ALLEOPs(2.11) through (2.14) we focused only on the cells and actions, likeplay(), work() and meet(), performed in the cells, and ignored signalexchange events and signal sensing operations. Then the ALLEOPs (2.11)through (2.14) yield the following FSP description of theimplementation:

E = [(readyToStart → [BILL || BEN]) | (interrupt → STOP)]; BILL = play →meet → E;   BEN = work→ meet → E  ;  (2.27)Here, E STOPs after an interrupt. This is not shown in the ALLEOPs butspecified in CIPs. We have here taken the liberty to include it here. Asper FSP conventions, FSP-synchronization occurs on meet and E. This iscalled coordination in TICC™. FSP does not distinguish betweensynchronization and coordination, as they are used in TICC™-paradigm.Also, FSP does not have a simple framework to specify temporalsynchronization of distinct actions (i.e. actions with different names),unless actions are renamed based on their synchronizationcharacteristics.

When cells contain multiple functionPorts, generalPorts andinterruptPorts, and actions are conditional, and messages are exchanged,then TIPs get complicated (as discussed in Section 4). FSP descriptionsthat correspond to ALLEOPs will also get complicated. Nevertheless, itseems, ALLEOPs of any application with a fixed finite number of portsmay be abstracted to obtain its equivalent FSP specification. Thus, itseems, ALLEOPs of every application with a fixed finite number of portsis a finite-ALLEOP.

Reverse translations of FSPs to their corresponding finite-ALLEOPs andimplementations will be hard, since (i) FSP does not distinguish betweensynchronization and coordination, (ii) identify states of communicationlinks or (iii) introduce the concept of transactions. For example, theFSP in (2.27) does not specify that after meet, E is informed about theend of the game, by synchronous and coordinated communications via Benand Bill. There are hidden states here (states of ports and agents)which do not appear in FSP. This happens because, FSP has no concept ofports, agents, transactions, pathways and protocols. We have notinvestigated adequately ALLEOP abstractions to FSP and FSP refinementsto ALLEOP, to comment further on these. The relationship between ALLEOPsand FSPs suggested by this discussion is significant, and should bepursued further.

All proofs that depend only on the structure of a finite-ALLEOP willhave the simplicity of FSP proofs. User defines CTL-assertions to beproven, and may also provide assertions to guide proof search. Thesystem verifies that every assertion provided by user is valid for thegiven implementation, before accepting it.

NFSP Proofs: ALLEOP-proofs that depend on values of variables used incomputations may require NFSP (Non-FSP) proof methods. Such NFSP proofsmay require induction over the structure of the ALLEOP. We will seesimple examples of both FSP and NFSP proofs in Section 6. For anapplication, in which the network grows dynamically during computations,its ALLEOP may be an NFSP ALLEOP containing context dependent andgeneral recursive structures with potentially infinite number ofALLEOP-nodes. An example is presented in Section 6.7.

The next example is an augmented version of the “Talking and Itching”example described in [Magee & Kramer, 13]. Here, it is intended toillustrate use of non-deterministic guard, concurrency, encapsulation,hiding and coordination.

2.2. Talking & Itching: Encapsulation, Concurrency and Coordination

A person talks and itches simultaneously. In [Maggie & Kramer, 13] thereis only one person and the person talks and itches with time slicedconcurrency. We consider a generalized version of that example with twopersons, where conversation takes place between them, and each personscratches intermittently while he/she is talking. The scheme could begeneralized to more than two people. An orderly conversation ismaintained with no more than one person talking at any one time. Thisexample uses a Das-pathway with a virtualMemory, which was introduced inFIG. 4.

The network is shown in FIG. 7. P0 and P1 are the two Persons. They arecompound (also referred to as composite) cells because they encapsulatea network inside them. Each person Pj, for j=0, 1, is a composite cell,containing of one Converse cell Cj and one Itch cell Ij. These two cellsrun in parallel in distinct CPUs in each person. Each composite cell hashidden internal connections and some have connections to external ports.Decomposition of a composite cell to define the network it encapsulatesis a step in called refinement. Let us first review the connections thatare internal and external to the two encapsulated cells and the networkactivities they support.

External Connections For j=0, 1, there is a pathway, [Cj.f0, Pj.f1, a1,a0, E.g1] (see FIG. 7). Here, ports [P0.f0, P1.f0] form a port-group;agent a1 delivers synchronized signals to [P0.f0, P1.f0] and deliversback to E.g1 coordinated signals from [P0.f0, P1.f0] via agent a0.Similarly, E.g0 is connected through an agent to the externalinterruptPorts in the port-group [P0.i, P1.i], which in turn areconnected to the internal interruptPorts, (C0.i, C1.i), respectively. Euses this pathway to activate cells Cj for j=0, 1. There is a pathway[Cj.f2, Pj.f2, Pk,g2, Ck,g2] for i,k=0, 1, and i≠k, which allowscommunications between Cj.f2 and Ck,g2. Similarly, pathway [Cj.f3,Pj.f3, Pk,g3, Ck.g3] enables communicates between Cj.f3 and Ck.g3.

Internal Connections: Pj.g has an internal connection to theinterruptPort, Ij.i. When Pj is activated it uses this connection toactivate Ij. Other two internal connections are, Pj.g0

Ij.f0 and Pj.g1

Ij.f1. Cj and Ij use these two connections to coordinate theiractivities.

Hiding: Only ports and agents linked to the external ports of theencapsulated cell, may be accessed from the outside world. Pathwaysinternal to an encapsulation are hidden from the outside world; we referto this as hiding.

Network Activities The environment E activates the Converse cells Cj forj=0, 1, by broadcasting an interrupt signal to ports in the port-group[P0.i, P1.i]. Once activated, the cells initialize, acknowledge receiptof interrupt signals, and then begin to poll their ports. Duringinitialization each cell Cj for j=0, 1 activates the Itch cell Ij bysending an interrupt signal to Ij.i through Cj.g (see FIG. 7). Thiscauses both the Itch cells Ij for j=0, 1 to begin polling afterperforming their own respective initializations. After activating theConverse cells, E broadcasts a randomly chosen 2-bit signal, [b₀, b₁],to ports in the port-group [P0.f0, P1.f0]. Restriction on these bits isthat they cannot both be 0's, or both be 1's. The agent a1 (see FIG. 7)sends delivery signal to P0.f0 (P1.f0) only if bit b₀=1 (b₁=1), else itdoes not.

When a person receives a signal at port Pj.f0 the signal goes to Cj.f0through the internal connection. When Cj senses this signal it begins totalk. Since b₀ and b₁ cannot both be 1, the two persons cannot bothbegin to talk simultaneously. While one person is talking the cells inthe other person will be polling their ports and just spinning, andpresumably listening to the talk. Before beginning to talk Cj sends asignal to Ij.f0 through Cj.g0 (see FIG. 7). When Ij senses this signalit begins to scratch intermittently, and continues to scratchintermittently while Cj is talking. Intermittent scratching iscontrolled by the Boolean variables, Ij.itching and Ij.continue.Scratching occurs only when both true. The truth values of Ij.itchingand Ij.continue are set in each scratching cycle, by a random truthvalue generator, Ij:random(). Thus, a person may not scratch throughouta talking session. There is an assumption here that scratching intervalswill always be much shorter than the talking intervals. Since the Itchand Converse cells operate in parallel, actions performed by them occurin parallel, even though the time-points at which a person begins totalk and begins to scratch are not synchronized to each other.

After talking, Cj first sends a signal through the pathway Cj.g1

Ij.f1. This informs Ij to stop scratching. Cj then does one of twothings: either (i) it signals Ck.f2 for k≠j through ports in thepathway, [Cj.g2, Pj.g2, Pk.f2, Ck.f2] (see FIG. 7) to advise Pk to begintalking in order to continue the conversation, or (ii) it signals Ck.f3through ports in the pathway [Cj.g3, Pj.g3, Pk.f3, Ck.f3] to terminatethe conversation. The way these mutually exclusive signals at the twofunctionPorts, Ck.f2 and Ck.f3, are used to continue or to stop aconversation is described below. One of the TIPs below uses anon-deterministic guard of the form (∃(f)(f=(Ck.f2|Ck.f3))f:mR?()). Thesymbol ‘|’ specifies alternates. Here, each cell Ck evaluates this guardin every one of its polling cycles. The guard evaluates to true only ifone of the ports among the alternates specified in the guard has asignal delivered to it. Signal deliveries to ports in the guard shouldbe mutually exclusive, in order for a non-deterministic guard to operatesuccessfully. If a signal is sensed at Ck.f2 then conversationcontinues, if it is sensed at Ck.f3 then conversation terminates. If theconversation terminates, then a signal is sent back to E.g1 via portCk.f0, if this port is ready to send that signal. Ck.f0 will be ready tosend that signal only if it had received earlier a signal from E.g1 viaagent a1 (see FIG. 7). Thus, only the cell that received a signal from Eresponds to it. Coordination occurs here, because at this point, agenta1 will be expecting to receive a signal only from the port to which ithad earlier delivered a signal. When a1 forwards this signal to E.g1, itwill inform E that conversation has terminated. At that point, E maystart another conversation session, or terminate the game by sending thesecond interrupt signal to the interruptPort Cj.i, for j=0,1. Cj willterminate Ij by sending an interrupt signal to Ij.i (see FIG. 7) beforeterminating itself. Starting and termination processes are not shown inthe TIPs below.

Cells in each person Pj for j=0,1 has the following polling cycles:

Cj:polling( ) = [Cj.f0:mR?( ) → (∃(f)(f = (Cj.f2 | Cj.f3))f:mR?( )     →Cj:polling( )] Ij:polling( ) = [Ij.f0:mR?( ) → Ij:polling( )]

Let us suppose Cj started the conversation and sent signal to Ck tocontinue the conversation. After sending this signal, Cj will beginpolling its ports, as per polling cycles above, presumably at the sametime listening to the other person talk (listening processes are notincluded in this implementation). Listening cell is not shown here. Cjmay go through multiple polling cycles, while conversation iscontinuing. This will cause the delivery signal received at Cj.f0 to berepeatedly sensed. Since no response is sent as long as the conversationcontinues, sensing of signal at Cj.f0 will succeed every time sensing isdone, as described in FIG. 1. Thus, while Ck is talking Cj may alsobegin to talk. To prevent this, Cj sets Cj.f0.input=(immediately aftersensing the delivery signal at Cj.f0. This prevents repeated sensing ofthe signal at Cj.f0. We use the statement, Cj.f0:suspend(), to do this.Since suspension does not change the state of a port, response may stillbe sent through a suspended port, when it is appropriate to do so.

With this preamble, and the comments given below reader should now beable to follow the TIPs described below.

For Person Pj, j = 0,1: TIPs for the talking part. Cj.f0:mR?(){Cj.f0:suspend( );//This prevents the signal at Cj.f0 from being sensedagain.     Cj.g0:pR?( )*{ Cj.g0:s( );}//Sends signal to Ij.f0 to beginscratching.     Cj:think( ).talk( );       Cj:g1:pR?( )*{Cj.g1:s();}//Sends signal to Ij.f1 to stop scratching.      /*signals Ck viaCj.g2 to continue conversation, or signals via Cj.g3 to terminate     conversation. When conversation is terminated, informs E about itby signaling via Cj.f0,      if it is ready to send the signal.*/     Cj:continue?( ){ Cj.g2:s( );}         else { Cj.g3:s( ); Cj.f0:pR?(){ Cj.f0:s( );}}} (∃(f)(f = Cj.f2|Cj.f3)f:mR?( ){//at this point thisguard fails at both Cj.f2 and Cj.f3.  //the guard will succeed only atCk.f2 or Ck.f3 for k≠j.  selectOne{//selectOne selects the first truecondition in a top down scan.   (f=Cj.f2)?( ){ Cj.f2:s( );//Responds toCk.g2 for k≠j.        Cj.g0:pR?( )*{ Cj.g0:s( );}//signals to Ij.f0 tobegin scratching.        Cj:think( ).talk( );        Cj:g1:pR?( )*{Cj.g1:s( );}//signals to Ij.f1 to stop scratching.        Cj:continue?(){ Cj.g2:s( );}           else { Cj.g3:s( );             Cj.f0:pR?( ){Cj.f0:s( );}}}   (f=Cj.f3)?( ){ Cj.f3:s( ); Cj.f0:pR?( ){Cj.f0:s( );}}}}(2.28) For Person Pj. j = 0,1. TIPS for the Itching part. Ij.f0:mR?( ){/*In the following, Ij.itching and Ij.continue are initialized to true.Thus, when a signal is sensed at Ij.f0, Ij begins to scratch andcontinues scratching while in the while-loop, as long as Ij.itching istrue. However, inside the while-loop, Ij.random( ) assigns random truthvalues to Ij.itching and Ij.continue, in every iteration. Thus,scratching may not occur throughout the time Cj is talking, and evenwhen it occurs it will be intermittent. It is assumed here thatscratching intervals will be much shorter than talking intervals. It isa requirement for this implementation to succeed.*/    while(Ij.continue?( )){ Ij:itching?( ){ Ij:scratch( );}         Ij.itching =Ij.random( );//This may stop the scratching.       Ij.continue =Ij.random( );//This may stop the while-loop       Ij.f1:mR?(){Ij.continue=false;}}//This stops the loop. /* There are two caseshere: (i) Ij.random?( ) made Ij.continue false or (ii) sensing signal atIj.f1 with in the while-loop made it false. Sensing Ij.f1:mR?( )* belowwould succeed in both cases, since response signal has not been sent yetvia Ij.f1. In the following, Ij will thus wait for signal at Ij.f1 onlyin case (i).*/    Ij.f1:mR?( )*{ Ij.f0:s( );//responds to cj.g0.         Ij.f1:s( );//responds to cj.g1.     //the following allowsscratching to start again when signal is sensed again at Ij.f0.    Ij.itching=Ij.continue=true; }} (2.29)

Conversation begins every time a signal is received either at P0.f0 orP1.f0. Scratching begins every time conversation begins or continuesintermittently. We leave it to the reader to figure out how correctcoordination occurs. The network does not provide for listening. Toprovide for this a third Listen cell should be introduced inside theencapsulation with proper coordination with Converse cell.

2.3. Perspectives

ALLEOPs: ALLEOPs integrate structural information provided by theTICC™-network, make explicit the control structure of parallelcomputations, synchronization and coordination that are implicit in theTICC™-network, the TIPs and Polling Cycles, and define partial orderingof time points postulated by time-maps. They present the integratedinformation in a form that is accessible to machine processing. For ahuman, they answer questions like the following: What does a pathway do?What is a TIP? What are polling cycles? What are communication patterns?The answers to these questions may go as follows: Pathway enablescommunication of signals between ports, performssynchronization/coordination of communications, provides access toexchanged messages, and activates parallel computations in the signalreceiving cells. TIPs process/create messages, send/receive signals, andisolate methods used for message processing/creation fromcommunications. Polling cycles, specify the order in which cells attendto TIP executions at their ports. Communication patterns arise becauseof choices made among alternate causal chains based on associatedconditions, and activations of parallel tasks (forks) through parallelsignal deliveries. Event patterns thus define patterns of branchings,forks and joins in control structures of parallel computations. Suchpatterns may be described using a regular grammar or other kinds ofgrammars that use ALLEOPs nodes as terminal symbols. ALLEOPs do notspecify details of computations performed by cells. Each ALLEOP noderepresents an event class. Multiple instances of an ALLEOP node mayoccur in a causalnet.

Just as the same sequential program may be run with differentdata-structure definitions, the same collection of pthreads defined foran application may be run in parallel in different TICC™-networks forthe same application. Thus, one may view TICC™-networks as abstractionsof control structures of parallel computations, just as data-structuresare abstractions of data manipulations in a sequential program.

Traces: Traces add information to ALLEOPs. They postulate virtual timepoints, associate them with event classes and time-maps that occur inALLEOPs in a manner that is consistent with ALLEOP specifications. Thusthey make explicit, timings that are implicit in ALLEOPs. Traces alsodefine the semantics of computations performed by TIPs, by associatingpre/post-conditions with actions and by characterizing exchangedmessages, if any. For a human, they answer questions like the following:What does an action compute? Is an action being correctly executed? Whatevents occur synchronously? What events are coordinated? The answers tothese questions may go as follows: An action is defined bypre-conditions that characterize what should hold true before itsexecution in order for the action to succeed, and post-conditions thatcharacterize what should hold true after the execution terminates. Thesepre-conditions and post-conditions may include in them characterizationsof messages processed/created by the action. An action implementation iscorrect if it's pre-condition and post-condition are both satisfied atappropriate moments, every time the action is executed. Events withidentical virtual time points are interpreted as occurringsynchronously. Message dispatching events with identical virtual timepoints are coordinated events.

Causalnets: Causalnets are abstractions of traces that focus only oncommunications event occurrences in traces and theirsynchronization/coordination characteristics, ignoring all conditionsand actions. They are generated by the SMS while an application isrunning. As explained in Section 7, Event Analyzer cells (ea cells) mayanalyze growing causalnets of applications in parallel withapplications, while causalnets are being created by Event Builder cells(eb cells), with little or no interference with timings of on goingoperations in applications. Analysis performed by ea cells may be basedon a priori defined event patterns, or event patterns that aredynamically learnt by the ea cells. It is even possible that patternsrecognized by ea cells are used to direct computations performed in anapplication.

The partially ordered domain for an application is simply arepresentation of all possible causalnets that SMS may generate for allpossible ways in which that application may run. It so happens, thisdomain together with a monotonic continuous mapping from the domain toitself, is sufficient to define the denotational semantics ofTICC™-Ppde. This is consistent with π-calculus view: Logic is not neededfor computations; communications with suitable hiding and substitutionrules are sufficient. Logic is needed only to define and provecorrectness of computations. That is why information provided by tracesis needed in order to prove CTL-assertions. ECTs reorganize informationin traces, and polling cycles and ECT-networks provide series/parallelcombinations of port-ECTs in an implementation. They are used forproving CTL-assertions. We will see some examples in Section 6.

Implementations presented in Appendices I through III and proofspresented in Section 6 illustrate the perspectives outlined above. Whatis significant is that ALLEOPs are easily automatically derived by thesystem from implementation specifications. Traces are easily andautomatically derived from ALLEOPs if pre/post conditions for actionsare made known to the system. TICC™-Ppde provides tools for interactivedevelopment of pre/post-conditions for actions. Four features ofTICC™-Ppde make this possible: (i) Organization of TICC™-network interms of cells with attached ports, pathways with agents and optionallyvirtualMemories; (ii) Organization of computations in terms of TIPs,polling cycles, pthreads and protocols; (iii) Integration of computationand communication: each cell that performs computations also performsall of its communications, using protocols that use CCPs; and (iv)Mutual isolation of cells (discussed in Section 3.2).

3. More on Cells and Pathways

3.1. Attachments and Tuning

Attachments and tunings have a special significance in TICC™. Onlyattached or tuned components may freely share each others data andmethods. Thus, attached and mutually tuned ports, cells, agents andvirtualMemories may freely share each others methods and data.

We use a.vM to refer to the virtualMemory attached to an agent, a; useM.a[i] to refer to i^(th) agent attached to virtualMemory M, and setp.vM=p.a.vM, where p.a is the agent to which p is tuned. For a cell C,C.p[j] is the j^(th) ports attached to C and C.vM[j]=C.p[j].vM. Onlycomponents connected to each other by branches or h-branches (hiddenbranches), or components attached to each other, may send signals toeach other in the pathway. In FIGS. 4 and 5, ports are attached to theirparent-cells, connected to agents by branches, and agents are connectedto each other by h-branches (they are h-branches because agentinterconnections cannot be dynamically changed, when pathways aredynamically modified). Thus, agents and ports, and pairs of agents, in apathway may exchange signals and cells may send signals to their ports.As mentioned earlier, pathways allow signal transfers only in onedirection at any given time, and components that exchange signals arealways tuned to each other.

Tuning: Connecting a port, p, to an agent, a by a branch b, tunes p toa, by setting (i) the initial states of p and a, which enables them toexchange signals between each other, and (ii) transfers to p addressesof data and methods in a.vM=p.vM, which enables the parent-cell of p toaccess data and pthreads in p.vM when the state of p is S. Thus, tuningp to a also tunes its parent-cell to the virtualMemory a.vM=p.vM. Sincea cell may have several ports, the cell may have several virtualMemoriestuned to it, distinct ones for distinct ports of the cell. Two agentsare tuned to each other by connecting them with a h-branch, which setstheir initial states.

Transaction Completion As mentioned earlier, cyclic polling of ports inevery cell guarantees that every service request sent to a port of acell is sensed and responded to. No cell may be interrupted while it isresponding to a service request. Cell senses and responds to interruptsonly between successive TIP executions. These features together withcell isolation described in the next subsection, guarantee transactioncompletion for every transaction and this keeps pathway componentsalways tuned to each other.

3.2. Cell Isolation

Cells perform computations by polling their ports and executingTIP-bodies defined at the ports. Since cells operate in parallel indistinct computing units, they provide a parallel execution mechanismand do not use time sliced interrupt driven pthread executions. Pthreadsand protocols are uniquely associated with cells and their ports. Eachport of a cell may have pthreads and will have a unique protocolassociated with it. Cell isolation is defined by the following twoproperties.

Private & Local Pthreads: While executing a pthread, a cell may only usedata and processes defined in the cell, or components attached to ortuned to the cell. No other data or process may be used during pthreadexecutions. In particular, the operating system cannot interfere with aTIP execution; in TICC™-Ppde operation system is not used at all toeither schedule or activated pthread or any method execution. A pthreadassociated with a cell may not be executed by any other cell, eventhough copies of the same pthread may be executed in parallel bydifferent cells, each in its own private memory or associatedvirtualMemory. A pthread execution can only change the state of the cellthat executes the pthread. These characteristics of cells are similar tothose of Actors and π-calculus-Agents.

Parent-cells of ports in a port-group (see FIG. 19) may simultaneouslyexecute the same pthread in the shared virtualMemory of the ports in theport-group. During such executions they may use common shared variables.We will see in Section 6.2 how pthreads are organized to block memoryinterference during such executions. Using dedicated virtualMemories toexecute pthreads and methods is unique to TICC™-Ppde.

Private & Local Protocols: Distinct ports have distinct protocolsdefined for them. A protocol defined at a port of a cell may not beexecuted by any cell other than the parent-cell of the port. Whileexecuting a protocol at its port, a cell executes CCPs and other actionstatements in the protocol over the pathway connected to that port (seeSection 7). Protocol execution does not cause the cell to execute anyother thread or process, not defined in the protocol itself. Nor does ituse data not defined in the components of the pathway. Distinct cellsmay execute in parallel only distinct protocols.³ As mentioned earlier,segments of protocols defined at the ports of a port-group are executedin parallel by the parent-cells of the ports over the samegroup-to-group pathway (FIG. 19), as described in Section 7. ³ Thusprotocols are methods defined at port instances, not port subclasses. Inour C++ implementation, this forced us to execute protocolsinterpretively, chasing through the components of a pathway. Thiscontributed to considerable inefficiency due to repeated cachereplenishments that occurred during protocol executions. Thus, eventhough it takes only 25 to 50 nanoseconds to execute a CCP in a 2giga-Hertz machine, it took 350 to 500 nanoseconds to execute a protocolwith four CCPs. This may be avoided by providing an Eval operator in C++similar to the eval operator in LISP, which may be used to evaluatecompiled protocols associated with a port, and by eliminating the use ofcache memories, as suggested later in this paper.

3.3. Parallel Buffering, Parallel Messaging and Mobility

No Sequential Buffers Ever Needed: No generalPort could send a secondservice request message to a functionPort, like for example, the portD.f in FIGS. 1 and 2, before the response to the first requested servicehas been received. This holds true for all generalPorts andfunctionPorts in a TICC™ network. Therefore, no virtualMemory will everhold more than one pending service request message at any time. Everypending service request message is preserved in its virtualMemory untilthe request has been sensed and responded to.

Similarly, every reply message is preserved in its virtualMemory untilit is sensed and used by the message receiving cell. No virtualMemorywill ever hold more than one reply message at any time. Thus eachvirtualMemory holds at most one service request and one reply at anygiven time. Distinct ports connected to distinct pathways will havedistinct virtualMemories associated with them. Thus, the virtualMemoriesin a TICC™ network provide a parallel buffering mechanism for servicerequests sent to a cell and replies sent by that cell. This eliminatesthe need for sequential buffers. Unlike Actor systems, there are nobuffer contentions to resolve, and serializers are not needed.

Parallel Message Transfers: We have already mentioned some of these. Wewill mention them again: (i) Each cell itself executes protocols neededfor message exchanges, in parallel with other cells. (ii) No twodistinct pathways share components in common. (iii) Each port isconnected to only one pathway. (iv) It is never possible that bothmessage sending and message receiving cells connected to a pathwaysimultaneously execute the protocol associated with that pathway. (v)Finally, no protocol executes any thread or process not defined in thecomponents of a pathway. Therefore, distinct protocols may be executedin parallel without mutual interference by distinct cells, whether theyare over point-to-point or group-to-group pathways. Thus, the number ofmessages that may be simultaneously exchanged in parallel among cells ina TICC™-network is limited only by the number of active cells and numberof distinct pathways in the network. CCPs keep pathway componentsisolated from cells and from each other.

Mobility: A sm-pathway connected to a port may be dynamically changed inorder to introduce mobility, as long as the following pathwayrequirements are not violated: (i) No port may be connected to more thanone pathway; (ii) no two ports of the same cell may be connected to thesame pathway, unless the ports are in a port-vector (see Section 4.2 andSection 7); and (iii) no two distinct pathways may share components. Themessage destination functionPorts of a sm-pathway may be disconnectedfrom the sm-pathway and routed to different destination functionPorts,in the middle of a transaction. Parent-cells of the new destinationports will then process the service request message in the virtualMemoryof the sm-pathway, write a reply message in that virtualMemory, andreconnect the sm-pathway back to its original destination ports, whoseparent-cells may then modify the reply, if necessary, and send it to thegeneralPorts that requested the service. Thus, reply is always sent backthrough the same pathway that delivered the service request. ThegeneralPorts connected to a pathway cannot be changed dynamically in themiddle of a transaction, but may be changed before a transaction begins.Neither generalPorts nor functionPorts connected to a dm-pathway may bedynamically changed in this manner.

By transferring the entire contents of a virtualMemory, M, tuned to aport C.p of cell C, to a different virtualMemory, M′, tuned to anotherport C′.p of another cell C′, after copying into M the state of C fromC′s private memory, one may transfer to port C′.p the functionsperformed at port C.p. This feature is useful in computationsdistributed over several SMPs interconnected by TICCNET™, in whichcontents of virtualMemories are transferred through dm-pathways.

3.4. TICC™, Π-calculus, Actors and CSP

TICC™ and Actors: In Actor systems, communication protocols invokeOS-methods and other processes that are external to Actors. Asynchronouscommunications require the use of sequential buffers. Serializers areneeded to resolve buffer contentions. One cannot predict when a messagesent by one Actor will arrive at a recipient Actor. Communications arenot order preserving: messages may not arrive at destinations in thesame order they were sent. Also, message transfer latencies are severalorders of magnitude higher than in TICC™.

In TICC™, unlike Actor systems, communication is connection oriented.Communication may occur between two cells only if a pathway between thetwo had been already established. Cells execute protocols by themselvesin order to exchange messages. Message sending and delivery times are inthe hundreds of nanoseconds range, which may be precisely predicted within given bounds. The only distinction between protocol executions andpthread executions in TICC™ is that protocols do not containdeclarations, but contain CCPs. Protocols thus define a restricted formof computation.

Besides transferring messages, protocols also transfer access rights todelivered messages, enforce a priori defined security restrictions onmessage deliveries, and drive the SMS (Section 8). All of these takeplace with no operating system involvement. Communications areintegrated with computations performed by cells; hence the name, TICC™,“Technology for Integrated Computation and Communication”. Also unlikeActor systems, TICC™ supports group-to-group communications, automaticsynchronization and coordination, and dynamic SMS (Self-MonitoringSystem). TICC™ eliminates the need for sequential buffers inasynchronous communications by using a parallel buffering mechanism. Itis not possible to define an SMS in Actor systems like the one inTICC™-Ppde. TICC™ provides unique synchronization and coordinationfeatures not provided by Actor systems. Support for transactions is notintrinsic to Actor systems.

All but two of the above mentioned differences also hold for π-calculus.

TICC™ and π-calculus: Both in π-calculus and in TICC™-Ppde, parallelcomputations are specified as interactions among parallel computingunits. Also, as in TICC™, communication in π-calculus is connectionoriented. Names are exchanged between π-calculus-Agents through alreadyestablished links, and links may be dynamically established. Instead oflinks, TICC™ uses pathways. Pathway connections may be dynamicallychanged as well. These are the only common features between π-calculusand TICC™-Ppde. Nothing else in the operation of TICC™-Ppde is similarto operations in π-calculus. Dynamic changes to pathway connections inTICC™ and dynamic changes to link connections in π-calculus seem toachieve different computational objectives, since changes made to apathway in the middle of a transaction have to be reset to theiroriginal configuration before the transaction is completed. There is noconcept of transactions in π-calculus.

The important difference between TICC™ and π-calculus is the following:pathway protocols define communication as a Turing computation [Turing,20] performed by interacting ndFSMs and executed by the same cells thatprocess, build and send out messages. Π-calculus does not specify acomputational mechanism for communications. Indeed, it is impossible tospecify the needed computational mechanisms using the π-calculusformalism. In this sense, π-calculus does not specify all of parallelcomputations. It specifies parallel computations only if communicationis assumed as a given primitive.

TICC™ and CSP: We have already mentioned the differences. We will statethem again. Pthreads in TICC™-Ppde correspond to CommunicatingSequential Processes, CSPs. Unlike CSPs, pthreads do not containcommunication primitives. Only TIPs contain communication primitives.TIPs isolate communications from interacting pthreads. Also unlike CSP,where channels block interacting CSPs, pathways do not block interactingpthreads. In addition, unlike CSP channels, pathways support bothpoint-to-point and group-to-group asynchronous communications withautomatic synchronization, coordination and data security enforcement.Concept of transaction is not built into CSP. Finally, it is notpossible to define SMS in CSP (Section 8).

Pair wise Independence of Pthreads: No method defined in one cellsubclass may ever invoke and execute another pthread defined in anothersubclass, unless the subclass instances are attached to or tuned to thecell. Two cells running in parallel may, however, execute copies of thesame method each in its own distinct execution environment. No methodexecuted by one cell may change the state of another cell. These holdtrue for pthreads as well. Pairs of pthreads executed by different cellsremain mutually independent of each other, except when a pair ofpthreads is simultaneously executed in the same virtualMemory bydifferent cells in a cell-group. This makes it possible to independentlyand separately verify most of the pthreads. When parent-cells of portsin a port-group execute pthreads from the same virtualMemory that iscommonly tuned to all of them (see FIG. 19), they use the scratchPadfacilities provided in the virtualMemory to coordinate parallelexecutions.

4. More on TIPs and TICC™-Ppde

4.1. Spawning New Computations

It is common that a cell, C, with a service request at one of itsfunctionPorts, C.f, could not by itself compute the response to areceived service request. In this case C may have to spawn newcomputations in one or more other cells in order to compute theresponse. TIP with the following format is used for this purpose:

  C.f:mR?( ){C.f:r(C.g); C.f:spwn?( ){ C.g:s( ); C.f:suspend( );}        else { C.f:s( );}} (4.1) C.f:suspend( ) is defined as,   {

C.f.state=S

(t₀)}[•→ C.f:suspend( )(t₀)]   {

C.f. input=φ

(t₁)} (4.2)where φ is the empty symbol. This prevents c from sensing the deliverysignal at port C.f in its ensuing polling cycles. We saw this used in adifferent context, in the Talking & Itching example in Section 2.2. In(4.1) the pthread C.f:r(C.g)=C.f:msg():r(C.f,C.g) is defined in thesubclass of the message in the virtualMemory tuned to port C.f.C.f:spwn?()=C.f.spwn, where C.f.spwn is a local Boolean variableassociated with C.f. The truth value of C.f.spwn is set in C.f:r(C.g).

TIP (4.1) does one of two things: After executing the pthread,C.f:r(C.g), the TIP sends out message either via port C.g or via portC.f, depending upon the value of C.f:spwn?(). The pthread, C.f:r(C.g)either writes a response message in the virtualMemory of C.f and setsthe Boolean variable, C.f.spwn=false, or writes a new service requestmessage in the virtualMemory of C.g and sets C.f.spwn=true. In thiscase, C spawns a new computation in the cell that receives the servicerequest sent via C.g and suspends its activities at port C.f. SuspendingC.f resets the delivery signal at C.f.input=φ. Thus, polling will failat C.f in ensuing polling cycles. After suspending C.f, C immediatelyproceeds to service its next port. Data and execution states in thevirtualMemory of C.f are preserved. C continues its activities at portsC.g and C.f only when it later senses a reply message at port C.g.Notice, in (4.2), suspension at C.f does not change C.f.state. Thus,when a response is received at port C.g and computations are resumed,C.f will be ready to send back a response.

Conditional statement with else-clause in (4.1),

C.f:spwn?(){C.g:s(); C.f:suspend();} else {C.f:s();},

is interpreted as follows:

selectOne{ C.f:spwn?( ){ C.g:s( ); C.f:suspend( );}     

C.f:spwn?( ){ C.f:s( );}       true{ }/*In this case C.f.spwn=φ*/},where selectOne scans its conditions top to bottom and selects the onethat evaluates to true. There is an unconditional escape clause, thelast one in selectOne. Thus, if C.f.spwn=φ then no message is sent out.This case will occur when the cell does not satisfy conditions requiredfor sending a message. In this case, the pthread that set C.f.spwn=(willreset C.f.input=s, if computations are to be resumed using the messagereceived at port C.f, or C.g.input=s, if computations are to be resumedusing the message received at port C.g. This will enable C to sensemessage at C.f or C.g in an ensuing polling cycle, and send message viaC.f, or C.g after the cell satisfies required conditions (see Section4.1.1).

When a message receipt is sensed at port C.g, in an ensuing pollingcycle, C executes a TIP with a similar body as the TIP in (4.1), withthe difference it now executes C.g:r(C.f) instead of C.f:r(C.g), usingthe message received at C.g, and the TIP repeats the same pattern ofmessage transmission.

C.g:mR?( ){ C.g:r(C.f); C.g:spwn?( ){ C.g:s( ); C.f:suspend( );}        else   { C.f:s( );}} (4.3)Spawning may thus be repeated as many times as needed, before a responseis sent back via port C.f and the transaction is completed. Completionof transaction is mandatory in every such computation. Here,C.f:r(C.g)=C.f:msg():r(C.g,C.f) is defined in the subclass of themessage received at port C.f and C.g:r(C.f)=C.g:msg():r(C.f,C.g) isdefined in the subclass of the message received at port C.g.

For each functionPort C.f the generalPort C.g, through which it mayspawn new computations, is unique. No other functionPort of C, may useC.g. This is intended to prevent possible deadlocks which may otherwiseoccur. One may also note, any time C sends out a service request viaC.g, the port C.g will be ready to send that message.

The cell to which C.g sends its service request may itself similarlyspawn new computations. Also, C.g may broadcast its service request to afunctionPort group. This may cause computations to spread over thenetwork. Every cell, to which service request is so sent is mandated torespond to it and will always do so. Eventually all spawned transactionsterminate and the response message is received by C.g. This responsemessage at C.g will then be used by C to respond to the service requestit received at C.f (or may be to spawn again).

4.1.1. ALLEOP and Trace with Alternates

We illustrate below occurrence of alternates in ALLEOP and trace due tobranchings caused by choice points. We choose spawning computationsspecified by TIPs (4.1) and (4.3) as examples. Let us assume that theport C.f in TIP in (4.1) receives its message from port B.g at atime-point in T(B.g, 1) and port C.g in TIP (4.1) communicates with theport D.f. The ALLEOP for TIP (4.1) will then have the form,

C.f:ALLEOP( ) = [C.f:ALLEOP-guard( ){C.f:ALLEOP-body( )}]C.f:ALLEOP-guard( ) = [C.f:mR?(

C.f^(D)

[T(B.g,1)])] C.f:ALLEOP-body( ) = [C.f:r(C.g) •→ //This sets C.f:spwn totrue, false or φ.     (C.f:spwn?( ){ C.g^(S)[T(C.g,0)]       →(

D.f^(D)

[T(C.g,1)]         || •→...•→ D.f:ALLEOP( ))        •→ C.f:suspend( )} |    

C.f:spwn?( ){ C.f^(S)[T(C.f,0)]        →(

B.g^(D)

[T(C.f,1)]         || •→...•→ B.g:ALLEOP( ))} |      true{ })] (4.4)In (4.4) the ALLEOP specifies alternates enclosed between parentheses ‘(. . . | . . . | . . . )’. The pthread C.f:r(C.g) in (4.1) will also havealternates specified by choice points corresponding to the alternates in(4.4), as shown in (4.5) below. C.f.vM in (4.5) is the virtualMemorytuned to C.f; similarly for C.g.vM.

C.f:r(C.g) = C.f:msg( ):r(C.g,C.f) =   [<computations-1> //this sets uptruth values for conditions   used below.    selectOne{<C.f:condn1>?( ){C.f.spwn=true;                <write-msg-in-C.g.vM>}      <C.f:condn2>?( ){ C.f.spwn=false;              <write-msg-in-C.f.vM>}            true{ C.f.spwn = φ;               C.f.input = s;}}] (4.5)

Notice, when C.f.spwn=φ is set in (4.5), C.f.input is reset to s so thatC may sense again the message received at port C.f in its next pollingcycle. In (4.5) when message is sensed again, the entire C.f:tip() in(4.1) will be executed all over again. It is also possible to resumeexecution of C.f:tip() from a specified address in the compiled code ofC.f:tip(). This is done by replacing ‘C.f.input=s;’ in (4.5) by‘C.f:suspendTIP();’, which sets ‘C.f.input=s;’ and sets the address ofinstruction in the compiled code of C.f:tip() at which C.f:tip() shouldresume operations (details in Section 8.2). The form of pthreadC.g:r(C.f)=C.g:msg():r(C.f,C.g) is shown below The only difference is inthe roles of C.f and C.g:

C.g:r(C.f) = C.g:msg( ):r(C.f,C.g) =   [<computations-2> //this setscondn1 or condn2 true.    selectOne{<C.g:condn1>?( ){ C.g.spwn=true;               <write-msg-in-C.g.vM>}       <C.g:condn2>?( ){C.g.spwn=false;               <write-msg-in-C.f.vM>}            true{C.g.spwn = φ;                C.g.input = s;}}] (4.6)The ALLEOP for (4.5) has the structure shown below with alternatespecification:

C.f:r.ALLEOP(C.g) =   [•→...•→ //this stands for <computations-1> in(4.5)   that sets values for condn1 and condn2..    •→ (<C:condn1>?(){C.f.spwn=true •→   <write-msg-in-C.g.vM>} |     <C:condn2>?(){C.f.spwn=false •→     <write-msg-in-C.f.vM>}|         true{C.f.spwn =φ •→ C.f.input = s;}})] (4.7)The ALLEOP for (4.6) is similar to this.

4.2. Port-Vectors

Forks and joins occur when port-vectors are used. A port-vector,C.p=[C.p₁,C.p₂, . . . , C.p_(n)], is a vector of ports, all of the samekind, all attached to the same cell C. In the TIP associated with thisport-vector, the parent-cell of the ports in the vector will use a guardhaving the form, C.p:mR?() (or C.p:pR?()) to check for messages (or tocheck port readiness), where

C.p:mR?()=[C.p₁:mR?() & C.p₂:mR?() & . . . & C.p_(n):mR?()] and  (4.8)

C.p:mR?()*=[C.p₁:mR?() & C.p₂:mR?() & . . . & C.p_(n):mR?()]*  (4.9)

and similarly for C.p:pR?(). Thus, the cell begins to respond to signalsat its port-vector only when all the ports in the vector have signalsdelivered to them (or all are ready). If guard is not true for all theports in the port-vector then the port-vector is skipped and theparent-cell begins to poll its next port in the asynchronous case, andrepeatedly evaluates the guard in the synchronous case.

In Tables 1 and 2, when g:mR?() test is performed at a generalPort g theinput signal s=g.input is reset to φ. This resetting of input signaldoes not happen for generalPorts g_(i) that belong to a port-vector, g,which constitute a subclass of the GeneralPort class. Thisspecialization enables g:mR?() tests to be successfully repeated insuccessive polling cycles before the test succeeds for all the ports inq in one of the ensuing polling cycles TIPs here have one of the forms:

C.f:mR?( ){ C:r(f); C.f:s( );} or (4.10) C.f:mR?( ){ C:r1(g,f); C:spwn?(){ C.g:s( ); C:suspend(f);}             else { C.f:s( )} (4.11) C.g:mR?(){ C:r2(f,g); C:spwn?{ C.g:s( ); C:suspend(f);}             else{ C.f:s(); C:suspend(g);}}, (4.12) C.p:s( ) = C.p₁:s( ); C.p₂:s( );C.p₂:s( );... C.p_(n):s( ); p=f|g. (4.13)In (4.11) ports in g did not have messages delivered to them. In (4.12),ports in q have messages delivered to them. In this case, when reply issent back via f, setting g.input=φ for every g in g, would signify thatthe message received through g has been listened to and used.C:suspend(g) in (4.12) performs this task. The pthreads, C:r(f),C:r1(g,f) in (4.10) and (4.11), and C:r2(f,g) in (4.12) are here definedin the common parent-cell of the ports in the port-vector. Theport-vector C.g is reserved for the exclusive use of C.f. It may benoticed, all the ports in C.g are always ready to send out messages whenC sends them out. The cell may use messages from only a subset of C.fdepending on computations defined in C:r(g,f) (or C:r(f)). Similarly, itmay send out messages that spawn computations only through a subset ofthe ports in C.q. In this case C will remember the generalPorts throughwhich messages are sent out, so that it can later listen for responsesonly at those ports. C always responds to every port in f.

Disjunctions are not allowed in guard expressions, except in the contextof non-deterministic existential guards described in Section 4.4. We sawan example using a non-deterministic guard in Section 2.2. However, adisjunctive response to received messages is possible depending upon howC:r(g,f) (or C:r(f)) uses messages received at the ports in C.f. Thus,it is possible that when a message is sensed at one of the ports of aport-vector, depending on the nature of this message, the messagereceived at another port of the same vector is ignored. The essentialdifference between specifying a guard with disjunctions, and theport-vector method is that in the latter case response occurs only afterall ports in the port-vector have received messages and are ready tosend responses, and anticipated computational contingencies fordisjunctive use are coded into the pthread. A reply is always sent backthrough every functionPort in the port-vector. An acknowledgement formessage receipt would be sent even if that message was ignored. Thustransactions would always be completed.

A consequence of this convention is that to introduce certain patternsof interactions among the ports in a port-vector of a cell, like forexample, where message at one port inhibits response at another port, itmay be necessary to change an already coded pthread that is used by thecell to respond to messages received through that port-vector. We optedfor this option, because avoiding disjunctions simplifies interactionspecifications and analysis of implementations.

4.3. Cycle Synchronization

Two ports in a network are said to be cycle synchronized if they bothservice their n^(th) input message (send out their n^(th) outputmessage) only after both of them have serviced their (n−1)^(st) inputmessage (sent out their (n−1)^(st) output message). Cyclesynchronization of a collection of distinct ports in a network forcesactivities at those ports to occur in a prescribed order. Thus cyclesynchronization of ports coordinates activities at those ports.

4.3.1. Types of Coordination and Synchronization

Coordination: As mentioned earlier, in (4.11) and (4.12) it is possiblethat the parent-cell of a functionPort vector, f, spawns servicerequests only through a subset of generalPorts in its associatedgeneralPorts vector, q. However, reply messages are always sent throughall the functionPorts in f. Thus, whereas the ports in f are cyclesynchronized and coordinated, ports in q are not.

This is the dual of what happens in group-to-group communications(Sections 2.2 and 7), where ports in a generalPort group G are alwayscycle synchronized and coordinated, and ports in a functionPort group Fare not. This is because, it is possible that a joint service requestmessage sent by ports in G is delivered only to a subset offunctionPorts in F. The particular subset of functionPorts to which agiven joint service request message was delivered may depend on themessage that was sent and on security specifications (see example inSection 2.2 and Section 7). The agent that broadcasts message deliverysignals to functionPorts F keeps track of the functionPorts to whichmessage is delivered, and will expect responses only from thosefunctionPorts.

Synchronous Joins and Forks: In a group-to-group communication thedispatch and delivery of messages that cause forks and joins are,respectively, coordinated and synchronized by agents in thegroup-to-group pathway, as described in Sections 1.3.2 and 7. Differentcells in a cell-group may begin responding to a synchronously deliveredmessage at different times, since the times at which responsecomputations begin are not synchronized. However, since communicationsare synchronous, we refer to these as synchronous forks and joins.

Asynchronous Joins and Forks: Messages received by ports in afunctionPort vector, f, constitute a join operation and messages sentout through the generalPort vector, g, constitute a fork operation.These messages may arrive (depart) at different times and come from (goto) different cells. Since communications here are asynchronous we referto these as asynchronous forks and joins. However, note that responsecomputations to messages received in asynchronous joins always beginsynchronously. Here, synchronization is done by the message receivingparent-cell of the port-vector.

Ad hoc Synchronization and Coordination: In Section 6.6 (FIGS. 17 & 18)combinations of spawning, port-group and port-vector organizations areintroduced, in which asynchronous messages received by any givencollection of distinct ports of distinct cells in a TICC™-network may becycle synchronized to force response computations to occur in aprescribed order, or forced to cause response computations to beginsynchronously in the message receiving parent-cells of ports, withouthaving to change any of the refinements done up to that point. We referto these as ad hoc coordination and synchronization, since they are doneas a after thought.

As mentioned earlier, TICC™-Ppde requires no monitors, semaphores and norendezvous [10,12,23,24] to coordinate and synchronize activities inparallel computations. We saw two examples of synchronization andcoordination without using monitors and semaphores, in Section 2 andwill see more in Section 6. Application developing programmers have noresponsibility to specify programs for synchronization, coordination orscheduling. They only have the responsibility to specify theTICC™-network. All of the rest is automatic.

All Synchronization and Coordination Methods Used in TICC™-Ppde areUnique to TICC™-Ppde and New to Programming Technology.

4.4. Non-Deterministic Guards

A non-deterministic guard chooses one alternative from a specifiedcollection. The TIP has the form,

∃(C.p_(i))(C.p_(i) = (C.p₁ | C.p₂ | ... | C.p_(n)))C.p_(i):mR?( ){     selectOne{(C.p_(i)=C.p₁)?( ){ C.p₁:tip( );}           (C.p_(i)=C.p₂)?( ){ C.p₂:tip( );}             ... ... ... ...... ... ... ... ... ... ... ... ...           (C.p_(i)=C.p_(n))?( ){C.p_(n):tip( );}} (4.14)Here p stands for (f|g). The first port with a delivery signal is chosenin a left to right scan of alternates in the guard. The cases have to bemutually exclusive if the alternates included a functionPort. Otherwise,a message received at a functionPort may not be responded to. As wementioned earlier, this is not allowed.

In the TIP (4.14) let us assume, C.p_(i), which is one of the alternateports in the guard, receives its input message from B.q_(i). The ALLEOPof (4.14) will then have the form, with alternate causal chains ofactivities:

∃(C.p_(i))(C.p_(i) = (C.p₁ | C.p₂ | ... | C.p_(n)))C.p_(i):mR?(<C.p_(i)^(D)> [T(B.q_(i),#)]{      ( (C.p_(i)=C.p₁)?( ){ C.p₁:ALLEOP-body( )} |       (C.p_(i)=C.p₂)?( ){ C.p₂:ALLEOP-body( )} |        ... ... ... ...... ... ... ... ... ... ... ... ... ... ... ... ... |      (C.p_(i)=C.p_(n))?( ){ C.p_(n):ALLEOP-body( ) )} (4.15)

One may also have a synchronous guard, ∃(C.p_(i)) (C.p_(i)=(C.p₁|C.p₂| .. . |C.p_(n))) C.f_(i):mR?())*. In this case scanning of the guard isrepeated until one port with a delivery signal is found. It is possiblefor this to succeed, since messages are delivered to ports of a cell inparallel with cell operations. This type of synchronous guard is used inthe Ornamental-Garden solution, OG-solution, in Section 6.1. Otherexistential guards have the form,

∃(i)(1≦i≦n)g_(i):mR?( ){ selectOne{(C.g_(i)=C.g₁)?( ){ C.g₁:tip( );}(C.g_(i)=C.g₂)?( ){ C.g₂:tip( );}  ... ... ... ... ... ... ... ... ...... ... ... ... (C.g_(i)=C.g_(n))?( ){ C.g_(n):tip( );} (4.16)containing only generalPorts. In this case, the different cases need notbe mutually exclusive, since it is not required that messages deliveredto generalPorts should be responded to. Here also the first port with adelivery signal, in a left to right scan of the guard expression, ischosen. ALLEOP is similar to (4.15). This kind of guard is used in theproducer/consumer solution, PC-Solution, in Section 6.3.

4.5. Port Dependencies

Function Computed at a Port: Every cell has its own internal memory. Itis the memory of the CPU that is assigned to that cell. It uses thismemory to execute pthreads defined in the cell and to store its localstate. For every port, C.f, of a cell, C, when C executes the TIP-body,C.f:tip(), the pthread it executes may compute the function,

ξ_(f)(m _(n) ,S _(C) [f,n−1])=(m _(n) ′,S _(C) [f,n])  (4.17)

where m, is the n^(th) message received by port C.f, residing in thevirtualMemory C.f.vM; S_(C)[f,n−1] is the state of C relative to itsport C.f at the end of execution of the (n−1)^(st) message at C.f,m_(n)′ is the n^(th) response message sent via port C.f, and S_(C)[f,n]is the state of C relative to C.f after execution. We will use P_(p) todenote the set of predicates defined on port p, and P_(C) to denote theset of predicates defined on cell C: ∀p∀q(p≠q

P_(p)∩P_(q)=φ) & ∀p(P_(p)∩P_(C)=φ). S_(C)[f,n]⊂(P_(f)∪P_(C)) willcontain the true predicates in (P_(f)∪P_(C)). The values associated withthese predicates are kept in the local memories of the cell and thevirtualMemory, C.f.vM. In (4.17) C.p:tip() can change the values of onlythe predicates in (P_(f)∪P_(C)).

Independent Ports Every port that computes a function of the form (4.17)is an independent port of cell C if S_(C)[f,n]⊂P_(f) with the proviso,ξ_(f) cannot change the predicates in P_(C), or no other port of cell Cuses the predicates in P_(C). A cell in TICC™-Ppde may have more thanone such independent port. If C.f is one of the independent ports of C,then it is possible to move C.f together with the pathway connected toC.f to a new duplicate cell, C′, where C′.f receives the same messagesthat C.f received and C′.f has the same functionality as C.f. In thiscase, all ports that are dependent on C.f (see (4.18) below) should bemoved to C′. One may assign multiple independent ports to a cell C tokeep the CPU assigned to C from becoming idle. InterruptPorts are alwaysindependent ports, but they cannot be moved to another cell, sincecomputations in a cell are started/stopped, suspended/resumed, or theordering of ports in the cell changed, based on messages receivedthrough its interruptPorts.

Dependent Ports For a port C.f₁ the function computed by C.f₁:tip() mayhave the form,

ξ_(f1)(m _(n) ,S _(C) [f ₁ ,n−1],S _(C) [f ₂ ,n−1])=(m _(n) ′,S _(C) [f₁ ,n])  (4.18)

where S_(C)[f₂,n−1] is the state of C relative to another port, C.f₂ ofthe same cell. In this case, the port C.f₁ is said to be dependent onport C.f₂. ξ_(f1) may use the predicates in P_(f2) but cannot change anyof them. This kind of port dependency is enforced by the TIP at C.f₂with the following nested form:

C.f₂:mR?(){C.f₂:r().s(); C.f₁:mR?()*(C.f₁:r(C.f₂).s()}}  (4.19)

Here, immediately after responding to a message at C.f₂, the cell waitsat C.f₁ to receive a message there and responds to it. One may havearbitrary number of such nesting in a TIP. It is possible that C.f₁ andC.f₂ are mutually dependent on each other. In this case the TIP has theform,

C.f₂:mR?(){C.f₂:r(C.f₁).s(); C.f₁:mR?()*{C.f₁:r(C.f₂).s()}}  (4.20)

Here, C.f₂ responds to its message first, using the initial statesrelative to C.f₁ and C.f₂, and then C.f₁ follows suit. Next time C.f₂responds to its message it makes use of the updated states relative toC.f₂ and C.f₁ and this cycle of interaction repeats itself in thepolling cycles of cell C. Clearly, ports C.f₁ and C.f₂ in (4.19) and(4.20) are cycle synchronized. In these cases, C.f₁:tip() is executedonly inside C.f₂:tip(). Thus, C.f₁ is not polled in polling cycles ofcell C.

Moving Dependent Ports: In FIG. 8, in the cell marked ‘original’, C.f₁is dependent on C.f₂ as in (4.18). In the ‘modified’ version, thepathway at C.f₁ has been moved to port C′.f₁ of another cell, C′, whichcontains the port-vector C′.f=[C′.f₁, C′.f₂]. The original port C.f isconverted to a generalPort C.g, and a pathway is setup between C.g andC′.f₂. The following TIPs at C.f₂, and the port-vector, [C′.f₁, C′.f₂]may be used to account for the dependency between C.f₁ and C.f₂:

(C.f₂:mR?()& C.g:pR?()){C.f₂:r(C.g).s(); C.g:s();}  (4.21)

(C′.f₁:mR?() & C′.f₂:mR?()){C′.f₁:r(C′.f₂).s(); C′.f₂:s();}  (4.22)

Here, C.f₂ writes a message in C.g.vM and sends it out to C′.f₂.Clearly, C.f₂ and [C′.f₁,C′.f₂] are cycle synchronized. It does not payto separate mutually dependent ports.

The possibility of moving dependent and independent ports to new cellsin this manner gives rise to the concept of canonical networks, whereeach cell contains only one independent functionPort or functionPortvector, and all other functionPorts are dependent on it.

Computations Dependent on Cell State: The function computed by C.f:tip()may also have the form.

ξ_(f)(m _(n) ,S _(C) [n−1],S _(f) [n−1]))=(m _(n)′,(S _(C) ′[n],S _(f)[n]))  (4.23)

where S_(C) is the state of the cell C and S_(f) is the state of portC.f. Here all the ports of C that share the state of the commonparent-cell are dependent on each other but they are not cyclesynchronized. As before, C.f:tip() may only change the predicates in(P_(C)∪P_(f)). In the Dining Philosophers solution in Section 6, allfunctionPorts of butler are dependent on the state of the butler. Inthis case, the output messages produced by a cell are dependent on theorder in which the input messages are processed. Since in any onepolling cycle of a cell, not all of its ports may have messagesdelivered to them, and message sensing is not synchronized with messagedeliveries; this is a source of non-determinism in TICC™-Ppde. Asmentioned earlier, it is intrinsic to parallel computations inTICC™-Ppde.

A functionPort f and a generalPort g of a cell may be mutually dependenton each other, as in the spawning TIPs (4.2) and (4.3). Here, port fleads the dependency, since g can have a message delivered to it onlyafter it has spawned a computation, which it may do only in f:tip(). Acell may use the generalPort dedicated to one of its functionPorts toget data from a database, or from the internet. A cell may also use itsgeneralPorts not dedicated to any functionPorts, to gather data forlater use, as in the Produce/Consumer example in Section 6.3.

TIP forms introduced in Sections 1 and 4 are the only forms of TIPs usedin TICC™-Ppde. There are a total of 10 TIP-forms, five of themsynchronous and five asynchronous. A TIP may have other TIPs embedded inits body and each TIP sends out zero or more messages. Let us refer to,TIPs at the ports of a cell that are polled by the cell in its pollingcycles are the polled TIPs and polled ports, and the rest embedded TIPsand embedded ports. At any given time, in all cases, each cell executesonly one polled TIP together with all its embedded TIPs. A cell executesits next polled TIP only after completing the execution of the currentpolled TIP, or after performing a programmed suspension of the currentpolled TIP. Polled TIP executions are mutually exclusive, Eachport-vector, C.p, has one common TIP, C:tip(

), defined for all the ports in the vector, and one common state, S_(C)[

,n] defined for all of them. C:tip(

) can change any of the predicates in

or P_(p)∪P_(C), depending on its functionality.

In all cases, the number of TIPs simultaneously executed in parallel bythe cells in a network, and the number of messages simultaneouslyexchanged in parallel, may be only as large as the number of activecells in the network.

4.6. System Architecture

It is instructive to contrast system organization in TICC™-Ppde withconventional system organization. FIG. 9A illustrates the conventionalarchitecture for concurrent/parallel thread/process executions, incoarse grained parallel programming. Libraries provided by MPI [25,26],PVM [27] and networks provided by Ethernet [22] or Myrinet [28] are usedfor communications. Actor systems assume this architecture. There aresignificant overheads for scheduling, communication, synchronization,coordination and process and thread management in these systems, withattendant loss of efficiency. TICC™-Ppde does not waste time onscheduling, coordination, synchronization and pthread management.

Real-Time Performance: There are only three kinds of operations that anycell in TICC™-Ppde performs: (i) polling and ordering ports (ii) pthreadexecution and (iii) protocol execution. It takes only 15-50 nanosecondsto poll and sort a port in TICC™-Ppde, with a 2-gigahertz computer.Message exchanges are self-scheduling self-coordinating andself-synchronizing. Pthreads and cell activations are self-scheduled aswell. They are automatically activated when delivered messages aresensed, or when a p:tip() is executed in the order specified bysorted-ports-list (see (2.1)). As shown in FIG. 9B, no operating systemis needed to perform these operations. All messages are sent as soon asthey are ready to be sent. Every cell may send a message in parallelwith every other cell at any time it is ready.

We call this real-time performance, since all available real-time isused for performing computations related to an application, and no timeis wasted on scheduling, coordination and synchronization sessions, orany other kind of overhead. No sequential buffers are ever used. ThevirtualMemory organization minimizes memory interference inshared-memory operations (Sections 6.2 and 8.2). These allow forefficient execution of parallel programs in TICC™-Ppde. Conventionalorganizations shown in FIG. 9A do not provide this kind of real-timeperformance.

Predictability: Established speed up technologies like multipleinstruction-stream executions [29], look-ahead scheduling [30],pipe-lined processing [31] and cached executions [32] make it impossibleto predict thread activation and execution times, and message dispatchand delivery times [Lee et al, 33-36]. These techniques are not neededin TICC™-Ppde, in order to get high throughputs. High throughputs may beachieved in TICC™-Ppde through arbitrary scaling of low grain sizedcomputations. We have predictable message exchange latencies and pthreadexecution times in TICC™-Ppde. Pthread activation times are predictablewith in bounded time limits. Timing is built into the event basedTICC™-Ppde models of computation.

Synchronization & Coordination: TICC™-Ppde provides novel methods forcoordination and temporal synchronization of events in an applicationwithout need to use monitors, semaphores or rendezvous [Hoare,10,12][Dijkshtra, 23,24]. These are illustrated in the examples inSections 2 and 6 and discussed in Section 6.6, and are unique toTICC™-Ppde.

Event Based Models: As we saw in Section 2, and shall see more inSections 6, 7, the most important characteristic of TICC™-Ppde is thatit automatically generates event based models of computations fromimplementation specifications, and these models are used for staticverification of the system through symbolic evaluations, and also usedfor the dynamic Self-Monitoring System (SMS). These features are uniqueto TICC™-Ppde. Event based semantics make TICC™-Ppde well suited forbuilding real-time cyber physical systems and embedded systems usingmulti-core chips, with precisely timed operations, if cache memories andother speed-up ornamentations are avoided. These simplify CPU design inmulticore-chips.

Before we proceed with examples that illustrate methods used toconstruct ALLEOP-proofs, it is useful to define the nature ofcomputation and communication in TICC™-Ppde, events and causalrelations, OO-organization and the notation. This we do in the nextsection.

5. Names, World States, Evaluators and Events

5.1. The OO-Structure

We begin with a finite set of names. Names may be concatenations ofsymbols in a finite alphabet. Let <names> refer to this set of names.Each name in <names> denotes something unique. Items denoted by namesare called containers and objects. There are three sets here: <names>,<containers> and <objects>. We use meta-symbols x, y, etc., to refer tonames in <names>. We use meta-symbols Δx, Δy, etc., to refer tocontainers denoted by x, y, etc. In this case, we write x.denotes=Δx andΔx.denotedby=x, and say xε<container-names>. We use meta-symbols b, c,etc., to refer to <object-names>, δb, δc, etc., to refer to objectsdenoted by b, c, etc. We write, b.denotes=δb=b.value, andδb.denotedBy={b}=δb.valueOf; ‘{b}’ is used here, since in general therecould be more than one name denoting the same object.<Objects>∩<containers>=φ and <container-names>∩<object-names>=φ,(<object-names>∪<container-names>)=<names>. Denotation is defined by amany to 1 mapping: <names>→<objects>∪<containers>. It is possible thatδb≡b or δb≡c; the value of an object-name may be identical to the nameitself, or another object-name. Thus,(<Objects>∪<containers>)∩<names>={b|∃(<name>c)(b.value=c)}.

When several container-names denote the same container Ax, we will setone of those names, say name z, as the distinguished container-name ofthat container, and set Δx.denotedBy=z. When several object-names denotethe same object, δb, then we set δb.denoteBy=δb.valueOf={c|c.value=δb}.We define the following predicates for names, x:name?()

xε<names>; x:container?()

x.denotesε<containers>, which is the same as saying xε<container-names>;x:object?()

x.denotes E<objects>, which is the same assaying xε<object-names>. Weuse three distinguished objects, respectively called true, false and φwith the property, δtrue=true, δfalse=false and δφ=φ; φ is the emptyobject. These are called constants, since the values of theseobject-names may never be changed: For any name, x, x: constant?()

xε<constant-names>⊂<object-names>, and δxε<constants>C⊂objects>.

We assert (x=y) iff the two names are identical to each other and assert(x≈y) if (Δx≡Δy) or (δx≡δy), i.e., x.denotes≡y.denotes. One may read(x≈y) as ‘x congruent to y’. Two names x and y are distinct iff

(x≈y). For two sets of names S₁ and S₂, [S₁⊂S₂

∀(xεS₁)∃(yεS₂)(x≈y)] & [S₁≈S₂

S₁⊂S₂ & S₂⊂S₁]. S₁∩S₂ and S₁∪S₂ are similarly defined.

Every container has the property that it can contain either an object oranother container. We write Δx.contains=δb or Δx.contains=Δy,

(Δx=Δy). Objects cannot contain anything: ∀(δx) δx.contains=φ. We say anobject δx resides in a container Δy if Δy.contains=δx. Every object hasto reside in some container; there are no free floating objects. Twoobjects that are identical to each other, but reside in distinctcontainers are called copies of each other.

  For z∈(<names> ∪ <objects> ∪ <containers>) we define method, z:eval():   z:eval( )= [z∈<objects>?( ){Z} |  z∈<containers>?(){z.contains:eval( )} |  z:object?( ){δZ} | z:container?( ){Δz:eval( )}](5.1)

Equality: Equality of names, objects and containers is defined asfollows:

((δx=δy)

 (δx∩δy)),  ((Δx=Δy)

 (Δx∩Δy)),  and ((x=y)

 ((x ∩ y)

 (x:eval( ) ∩ y:eval( ) ≠ φ))) (5.2)This definition of equality may be extended to define (xεX) for a set X,and X=Y, X⊂Y, X⊂Y, X⊃Y and X⊃Y for sets X and Y. Notice, z:eval()=φ ispossible. However, names with empty values cannot be equal to each otherunless they are identical to each other; (x≈y)

(x=y) but the converse is not true, since distinct names may evaluate tocopies of the same δb.

One may think of containers Δx as memory-cells and container-names x aspointers (addresses) of those memory-cells. One may think of each δb asthe encoding (bit-string) that represents the object, b, and resides ina memory-cell. A pointer points to an object only if the encoding ofthat object resides in the memory-cell pointed to by that pointer.Objects in containers (memory-cells) may be modified without having tochange copies of those objects, which may exist in other memory-cells.We refer to the terms, “denotes”, “valueOf” and “contains” asattribute-name, and x:attribute-name as an attribute. Terms “object?()”,“constant?()” and “container?()” as predicate-name andx:predicate-name?() as a predicate. For any x: attribute,x:attribute=name, is a predicate, which is true iff x: attribute:eval()=name: eval(). Term “eval()” is a method-name and the term x:eval() is a method. We will be introducing more attributes, predicatesand methods defined for names as we encounter them, in our discussionbelow.

Orderings: For S⊂<objects> with an ordering relation, <, defined on itselements, and names x and y,

(x<y)

[x:eval()εS & y:eval()εS & x:eval()<y:eval()]  (5.3)

It is possible that φεS. Usual definitions apply for (x≦y), (x>y) and(x≧y).

Structures: If b has an indexed structure and for a name, x, x:eval()=δbthen x[i]=δb[i]=b[i] for i in the range of indices of b, else x[i]=φ.However, x[i]=φ does not imply that i is out of the range of indices ofb, since it is possible that the value of b[i] has been set to φ. Anx[i] itself may have an indexed structure, x[i][j]. If b is a structurewith attribute, b:atbt, defined for it, then x.atbt=b.atbt=δb.atbt, andx.atbt=φ if b.atbt is not defined. It is possible that b.atbt itself hasan attribute, b:atbt.atbt₁. Then,x.atbt.atbt₁=b.atbt.atbt₁=δb.atbt.atbt₁.

Groupings of Names: Every name, x, has a method, x:names(), defined forit; x:names() is the set of all names associated with x. It will includex, and all x.attribute, x:predicate?() and x:method() defined for x, andmay in addition contain other names as well. Since, {x}⊂x:names(), it isnever empty. For two distinct names x and y, it is possible thatx:names()∩y:names()≠φ; φ:names()={φ}. For any name x the closure ofx:names(), written as [x:names()], is

[x:names()]=∪{[y:names()]|yεx:names() &

(y≈x)}∪{x}  (5.4)

Typing of Names: A name may have a type associated with it, such asinteger, number, string, set, structure, class, etc. <Type> is the setof all type names. The method, x:type() is used to refer to the type ofname x: x:type()=Δx:type()=x: eval(): type(), and b:type()=δb:type();φ:type()=φ. Each type denotes a subset of names in <name>:type:names()={x|x:type()≡type}⊂<name>. Clearly,type:type()=Δtype:type()=Δtype.contains:type()=set.Type₁ is a subtype oftype₂ iff (type₁⊂type₂)

(Δtype₁.contains⊂Δtype₂.contains). Thus, (integer⊂number) holds. Type₁and type₂ are distinct if (type₁∩type₂)=φ. Two types neither of which isa subtype of the other, should be distinct. We use the usual conventionsfor inheritance within a type/subtype hierarchy, abstract types, etc.The OO-structures of names associated with a system S is outlined below.

The OO-Structure of a System S: Let W_(S)(t) be the world-state ofsystem S at time t.

W_(S)(t) = ({(x,Δx)|x:container?( ) & x.denotes=Δx & x∈S:names( )(t)}∪{(b,δb)|b:object?( ) & b.denotes=δb & b∈S:names( )(t)}∪{(Δx,Δx.contains)|∃x∃b∃y[((x,Δx),(y,Δy),(b,δb) ∈ W_(S)(t)) &    (x,y,b∈S:names( )(t)) &

(Δx∩Δy) &     (Δx.contains=δb

 Δx.contains=Δy)]}) (5.5)

We use only discrete time: Each time point, t, is a positive integer. If(t₁<t₂) then W_(S)(t₁) is the immediate predecessor of W_(S)(t₂), iffthere are no other time points t′ such that W_(S)(t′) exists and(t₁<t′<t₂). We use x(t) to assert that (x,Δx)εW_(S)(t) and∃(b)(b.denotes=x:eval()) and refer to x(t) as the access predicate;x(t)=[x, Δx, x:eval()], if x is a container-name. For an object name, b,b(t)=[b, Δb, δb]. It is possible that x:eval()=φ. We say accesspredicate x(t) is true if an evaluator (subsection 5.3) has accessed thetriplet (x, Δx, x:eval()) from world state W_(S)(t). Other eventpredicates are, (x=y) (t), which asserts that (x=y) was found to be truein W_(S)(t), and similarly for (x<y) (t), (x>y) (t), (x≦y) (t) and (x≧y)(t). Predicates relating sets are also used: (xεY) (t), (X⊂Y) (t), etc.Predicates have an ordering: x(t₁)<y(t₂) iff (t₁<t₂). Notice, (x<y)(t)is not the same as x(t₁)<y(t₂); It is possible that((x<y)(t₁)<(y<z)(t₂)). Time parameter is omitted if it is not important.

Let S: cells() denote the set of all cells in system S. For port C.p ofcell C, C.p.a is the unique agent tuned to C.p; C.p.pathway is theunique pathway connected to C.p; C.p.pathway.vM=M=C.p.vM=C.p.a.vM, isthe unique virtualMemory M of C.p.pathway that is tuned to C.p andC.M.a[i] is the i^(th) agent attached to M; M. ports [i] is the i^(th)port tuned to M; a.ports[i] is the i^(th) port tuned to agent a;C.ports[i] is the i^(th) port tuned to cell C; C.p.ndFsm is the ndFSMembedded in C.p; C.p.a.ndFsm is the ndFSM embedded in C.p.a; andC.vMs={C.p.vM|(C.p attachedTo C)}. If C.p is connected to a dm-pathwaythen C.p.pathway.vMs is the vector of all virtualMemories in thedm-pathway; C.q.MεC.q.pathway.vMs for every port q connected adm-pathway. Finally, a.nxt[i] is the i^(th) next agent tuned to agent a.The vector, M.ports=∪[M.a[i] ports|0≦i<M.a:size()]. Agents,virtualMemories and ports are the pathway components. The followingnames are associated with C.p.pathway:

C.p.pathway:names( ) = C.p.vM:names( ) ∪ ∪{C.p.vM.a[i]:names( )|0≦i<C.p.vM.a:size( )} ∪ ∪{C.p.vM.ports[i].ndFsm:names()|0≦i<C.p.vM.ports:size( )} (5.6)Here, C.p.vM:names() will contain all the names defined in the messages,methods and attributes that reside in C.p.vM. Notice, not allC.p:names() are in C.p.pathway:names(), only C.p.ndFsm:names() areincluded. As we shall see in Section 6.2, each virtualMemory has fourcomponents: Two of them, called the readMemory and the writeMemory,contain messages. At any given time each one these two components maycontain at most only one message. For every port C.p attached to cell C,

C.p.ndFsm:names()⊂C.p.pathway:names(),  (5.7)

C.p.ndFsm:names()⊂C.p:names()⊂C:names(),  (5.8)

Thus, C:names() and C.p:names() do not contain all the names inC.p.pathway:names(), they only contain the C.p.ndFsm:names(). At compiletime the evaluator E_(C) is given access to all names in [C:names()].For any two pathways and distinct cells, C₁, C₂, and any two ports, pand q, the following holds true:

 C₁:names( ) ∩ C₂:names( ) = φ, (5.9)  (p.pathway:names( ) ≅q.pathway:names( ))

 (p

 q) (5.10)

(p

 q)

 ((p.pathway:names( ) ∩ q.pathway:names( )= φ), (5.11)where (p

q) asserts that p and q are connected by a pathway. Notice the use ofthe congruent relation ‘≈’ in (5.10). In the case of (5.11) the pathwaysare said to be distinct. Distinct cells and distinct pathways nevershare containers. The invariant (i.e., compile time) OO-structure ofnames in S:names() in a system S, may now be defined as follows:

S:names( ) =  ∪{C:names( )|C ∈ S:cells( )} ∪  ∪{C.p.pathway:names( )| C∈ S:cells( ) &             (C.p attachedTo C)} (5.12)World states are compartmentalized into C:names() andC.p.pathway:names(), which overlap with each other only at theC.p.ndFsm:names(). We will see, how this overlap together with accessrights dynamically given to evaluator E_(C) at run time, enablescommunication among ports connected by pathways. A refinement of thisstructure is used to facilitate definition of methods. In the case ofdm-pathways ndFSMs in the pathway are connected to each other by signallines and virtualMemories are connected by data lines. Signals and dataare exchanged among containers via these lines, coordinated by CCPs inthe protocols.

5.2. Conditions and CTL-Statements

We use the term ‘guard’ to refer to predicates and predicate expressionsthat test for signals, term ‘state’ to refer to predicates and predicateexpressions that describe states of ports and agents, and use‘condition’ to refer to all predicates and predicate expressions. Acondition is any well-defined first order expression containingpredicates with logical connectives and quantifiers, or it is a Booleanexpression of predicates. All conditions end with the suffix ‘?()’.Quantifiers range over finite sets. A condition is always evaluated in aworld defined by the names in x:names(), where x is a cell, port, agent,virtualMemory or message.

A CTL-statement (Causal Temporal Logic statement) is any combination ofequality, ordering, access and event instances, and predicates, with theusual logical connectives, temporal modal operators, □ (always) and ⋄(eventually), and causal connectives, →, → (described below), usingquantifiers, ∀ and ∃, with the usual syntax. Negations may appear onlyon individual predicates and event instances and not on expressions as awhole. A negated event instance is interpreted as “the event instanceshould not occur”. Event instances have the status of both constants(two event instances are equal to each other if and only if they areidentical to each other) and predicates (negations by appear with eventinstances). The quantified variables in, ∀ and ∃ may range over eventinstances, virtual time points, and other objects appearing in aCTL-statement. Quantifiers range over a priori known finite sets. Wewill not describe here the syntax of CTL-statements. Statements used todescribe ALLEOPs and traces in several previous sections areCTL-statements. More examples appear in later sections. Proofs do notinvolve making logical deductions on CTL-statements, but only involvesymbolic evaluation of CTL-statements over given ECT-networks. We willsee examples of ECT-networks in Section 6.

5.3. Evaluators, Events & Causation

There is a structured constant called evaluator. A system may havearbitrary but finite number of evaluators, E[i], for 0≦i<N>0. We willnever encounter a need to refer to evaluators explicitly in ourdiscussions. But the concept is important. In TICC-Ppde there is anevaluator (CPU) associated with every cell and all evaluators operate inparallel, interacting with each other only through message exchanges.Let E_(C) be the evaluator of cell C. Evaluators perform computations,by creating/destroying names, containers, objects and encodings,modifying encodings, placing encodings in containers, placing containersin other containers, moving objects/containers from one container toanother, moving containers from one name to another, and setting accessrights to containers, and accessing objects (their encodings) from worldstates. These are the action and access events. Computations performedby evaluators cause access and action events to occur. When evaluatorE_(C) accesses a name x from W_(S), it will add the triplet, (x, Δx,x:eval()) to E_(C):accessedItems list. At the end of an evaluation itmay use the elements in E_(C).accessedItems to perform a consistentupdate of W_(S) and then destroy its private E_(C).accessedItems list.

A name x, is created (destroyed) in a world-state W_(S)(t) if x(t) istrue (false) but x(t′) is false (true) in the immediate predecessorW_(S)(t′). The general convention is, a predicate is true in W_(S)(t₂)if there is a t₁≦t₂ such that the predicate is true in W_(S)(t₁), andthere is no t′, t₁<t′≦t₂ such that the predicate is false in W_(S)(t′).Thus, names exist in world states until they are destroyed, andpredicates maintain their truth values until they are changed.

5.3.1. Access Rights, Data Protection and Communications

The only difference between communication and computation is thatcommunication protocols may only create/modify/destroy objects (data)that are in already defined containers associated with ports, agents andvirtualMemories in a pathway. They cannot create/destroy containers.This is because, they do not contain declarations. Neither can theymodify messages or other data in virtualMemories. Thus, communication issimply a restricted form of computation, with the difference thatcommunication transfers besides signals, also access rights toevaluators. Consider an evaluator E_(C) of cell C, and a pathwayC.p.pathway. Let us suppose E_(C) executes eval(C.p.protocol) to deliverto one or more ports C.q delivery signals. We then say the relation,(C.p deliversTo C.q) is true. Let E_(C).hasAccessTo(t), specify the setof all names E_(C) can access at time t. E_(C).hasAccessTo(t) is definedas follows:

E_(c).hasAccessTo(t) =   E_(c):names( ) ∪ C:names( ) ∪  ∪{(C.q.pathway:names( )(t)|    (C.p deliversTo C.q) & (C.q.state =S)(t)} (5.13)Of course, in this case C.q.pathway=C.p.pathway since both C.q and C.pare connected to the same pathway. Here, C.q.pathway:names() is afunction of time because the virtualMemory of the pathway may containdifferent messages at different times and also the pathway may changedynamically. Access rights for the names in C.q.pathway are transferredto E_(C) only when C.q is in state S. Thus, if two ports p and q areconnected by a pathway and a message is being exchanged between p and q,then exactly one of p or q should be in state S, and the evaluator ofthe cell that delivers the message will have access to bothp.ndFsm:names() and q.ndFsm:names(). This enables communication betweenthe ports p and q.

As described in Tables 1 and 2 a port always changes its state to S whena message is sensed or when the port is ready to send out a message.Thus in TICC™, communications automatically transfer access rights toevaluators, when a cell C begins execution of C.p:tip() at one of itsports and revoke the access rights when C completes the execution ofC.p:tip(). Polling a port C.p accesses only the names defined inC.p.ndFsm and access to these names are always available to E. However,delivering a message from port p to port q accesses bothC.p.ndFsm:names() and C.q:ndFsm:names(). Access to both of these becomesavailable to an evaluator at message exchange time. We use this propertyin Section 8.2 to propose a new shared-memory organization that exploitsvirtualMemories.

Evaluators have the property that they can evaluate actions, events andnames. Action is always a method, protocol or condition, or simply astatement in a programming language: a declaration, assignment,conditional (like if-then-else and selectOne) or a while-loop. Adeclaration appearing in a method, y:A(), defined in a cell, message,port, agent or virtualMemory, y, introduces triplets (x,Δx,x:eval())into y.A:world()(t) for the declared name, x. We use declarations alsoto destroy and remove names from y.A:world()(t). In additiony.A:world()(t) contains {(x,Δx,x:eval())|∃(X) (X⊂(y:names()∪A:names()) &(xεX:names()))}; y.A:world()(t) will also contain the compiled code fory.A() and may contain names that are dynamically created when y.A() isbeing executed. Protocols are actions with the difference that they donot contain declarations but do contain CCPs. Thus, protocols do notdynamically create or destroy containers. Methods usually do not containCCPs.

We use →_(a) for access evaluation →_(e) for action evaluation, with thefollowing notations:

Access Completed at time t: [

→_(a) x

 (t)] and Access Started at time t: [→_(a) x(t)] (5.14) Eval Completedat time t: [

→_(e) x:A( )

 (t)] and Eval Started at time t: [→_(e) x:A( )(t)] (5.15) EvalCompleted at time t:

x:C?( )

 (t) and Eval Started at time t: x:C?( )(t₁) (5.16)Applying an evaluator to a name x, action x:A(), or condition x:C?() maycause new events (described below) to occur, which may in turn causeother evaluations and occurrences of other events. For this reason, werefer →_(a) and →_(e) as causal relations. They are irreflexive,asymmetric and transitive. Evaluators not only cause events to occur,but they may also evaluate communicationEvents as described later below.

Note on Time Instances: It is possible that two time instances t₁ and t₂are incomparable, because they are measured in local clocks of differentevaluators, which are not synchronized to each other. But every clocktime has a unique 1-1 mapping to a global time. We use, x.t₁, y.t₂ torefer to local time points associated with two different objects x andy. The inequality, (x.t₁<y.t₂) may hold in the local times of x and y,if x and y either belonged to the same cell, or attached/tuned to thesame cell. Otherwise, (x.t₁<y.t₂) may hold only relative to mappings oftime points x.t₁ and y.t₂ to the global time in a designated globalclock. Several local clock time points may map to the same global timepoint; thus several events may occur in different distinct cells atdifferent local times, but all at the same global time. All time pointsare discrete time points that map to integers≧0.

Access Evaluation As mentioned earlier, the notation, x (t), is used todenote the event where an evaluator got hold of the triplet (x, Δx, x:eval()) from the world W_(S)(t). Clearly, an evaluator E may access xonly if it had the access right for it, i.e, xεE_(C).hasAccessTo(t).When evaluator thus accesses x, it would then have access to all namesin the closure, [x:names()]. In the following we define evaluators →_(a)and →_(e). When necessary, we write ^(E)→_(a) and ^(E)→_(e) toexplicitly refer to the evaluator E that does the evaluations. Accessevaluation may now be defined as follows:

□ ∃(τ>0)[{(x,Δx)∈W_(S)(t) & x∈E.hasAccessTo(t)}[^(E)→_(a) x(t)]       {W_(S)(t)=W_(S)(t+τ) & x(t+τ)}] where x(t+τ)= [

x,Δx,x:eval( ))∈E.accessedItems

(t+τ) &     

[x:names( )] ⊂ E.hasAccessTo

(t+τ)] (5.17)It always takes some time, τ>0, to complete the access. If access issuccessful, then it causes the event x(t+τ) to become true. Here theaction does not change the world state W_(S); only the local state ofthe evaluator E changes. Once x is accessed at time (t+τ), (x, Δx,x:eval()) gets into E.accessedItems at time (t+τ) and E gets accessrights to all names in the closure,

[x: names()]

(t+τ). If the pre-condition in (5.17) is not satisfied then the accessattempt will return φ. Since we use the convention that predicates inworld states always maintain their truth values, unless changed, it isnot necessary to specify the frame statement, W_(S)(t)=W_(S)(t+τ), in(5.17). We assume here, that local states of evaluators are distinctfrom world states; thus, the triplets appearing in E.accessedItems willnever occur in world states, even though components in the triplets formrelational structures in the world states, as described earlier.

Action Evaluation Action evaluation, ^(E)→_(e), is defined as follows:For a name x,

[^(E)→_(e) x(t)] = [^(E)→_(a) x(t)] = x(t) and for an action, x:A(...),(5.18) {

x.A:preC?( ) & ∃(S)∀(y∈S)[(S ⊂ x.A:world( ))     &

((y,Δy,y:eval( )) ∈ E.accessedItems)

(t)]}  [^(E)→_(e) x:A(...)(t)]{(x.A.output(t+τ) & x.A:pstC?( )(t+τ)}(5.19)Here, x.A:prec?() is one part of the pre-condition for x:A(). Its otherpart is that it must have accessed all needed names in x.A:world().Similarly, x.A:pstC?() is one part of the post condition for the action.It specifies changes to the world state W_(S), produced by the executionof x:A(). The other part of the post condition is x.A.output, which isthe output produced by x:A(). It could be φ. The condition x.A:preC?()and all specified accesses in the pre-conditions should be true, inorder for the evaluation of x:A() to succeed. Evaluation is correct ifit succeeds and the post-conditions hold true in the world state W_(S)(t+τ). Since occurrences of access events and condition checking do notchange the world, evaluation may be performed in the same world in whichthe pre-conditions are true. The context of evaluation for this actionis the subset S of x.A:world()(t).

Hereafter, we will omit the prefix superscript, E and subscripts a and ein ^(E)→_(a) and ^(E)→_(e) and simply write the evaluation as →,assuming →_(a) is subsumed in →. For a constant, c, (→_(e) c)=(→_(a)c)=(c, Δc, δc) at all times; by default certain constants are implicitlyassumed to be always present in all world states. We will not hereafterhave occasion to refer to access evaluations, ^(E)→_(a).

Pthreads are methods, a subset of actions. Methods are defined usingfour kinds of programming statements: Declarations, Assignments,Conditionals (like if-then-else and SelectOne), and While-loops.Declarations create/destroy containers and objects, may set contents ofnewly created containers, and cause triplets (x,Δx,x:eval()) to beintroduced into or removed from method:world() at compile/executiontime. Other statements in a method definition may cause objects andcontainers to be modified, contents moved from one container to another,or denotations of names changed. During its execution, a method changesonly the local state in method:world(). At the end of its execution theevaluator may use this local state to perform a consistent update of theworld state, W_(S)(t). Since W_(S)(t) is compartmentalized as defined in(5.11), cell isolation (Section 3.2) guarantees that multiple parallelupdates to W_(S)(t) may be done by different cells operating inparallel, without mutual interference. Semantics of program statementsthat appear in method definition may be easily defined. We use programstatements informally here, assuming reader would know the intendedmeanings. Characterizations of CCPs used in protocols were presented inTables 1 and 2. For most statements used in pthreads and protocols,TICC™-Ppde can automatically generate the associated pre and postconditions in given contexts, but user interaction may be necessary todefine certain pre-conditions and loop invariants.

5.4. Notation and Definitions: Evaluation of ALLEOP Nodes

We saw in Section 2 examples of action and communication events thatoccur in ALLEOPs and traces. In the following, we use symbols X, Y, Z, .. . for ActionEvent classes and symbols X[t( . . . )], Y[t( . . . )],Z[t( . . . )], . . . for CommunicationEvent classes. These event classesrefer to ALLEOP nodes. They are subclasses of the top level classcalled, Event. We use symbols, x(t), y(t), z(t), . . . to denote eventinstances; x(t) specifies that the instance, x, occurred at time t (seeFIG. 6B). If x(t) is an instance of the CommunicationEvent subclass,X[T(<port>, #)], then tεT(<port>,#). x(<port>.t_(#)) refers to theoccurrence of instances of X[T(<port>,#)] at virtual time points,<port>.t_(#)εT(<port>,#),in a trace (see for example, the trace in(2.18)). In a run of an application, multiple instances of thecommunicationEvent subclass, X[t(<port>,#)], may occur in a causalnet.The set of time-points at which those instances occur in that causalnetconstitute the sequence of strictly increasing time-points<port>.t_(#)εT(<port>,#) for that run of the application (see FIG. 6C).

CommunicationEvents: We introduce below the ‘forward’ variation of‘send’ command used in Section 2. In the following p,q=(g|f), p≠q.

-   -   p^(D)[T(q,#)]: A message is Delivered to port p by port q with        time-map in T(q,#).    -   P^(S)[T(p,#)]: A message is Sent by p with time-map T(p,#).    -   p^(F)[T(p,#)]: A message is Forwarded by p with time-map T(p,#).        Forwarding transmits a received message (may be with some        modifications), and sending transmits a newly created message.        We will see the precise distinctions in Section 6.2. In the        following [→p^(S|F)(t₀)] refers to starting of the occurrence of        first event in a message (sending|forwarding) process at port p        that started at time t₀; [        →p^(S|F)        (t₁)] refers to the ending of that event occurrence at time t₁,        (t₀<t₁). The following characterizations hold true for        CommunicationEvent evaluations during protocol executions and        guard evaluations:

 ∃[(t₀ < t₁) 1. {

g:pR?( )

 (t₀)}[→ g^(S|F)(t₀)]{

g.state=R & g.input=c|f

(t₁)} 2. {

f:mR?( )

 (t₀)}[→ f^(S|F)(t₀)]{

f.state=R & f.input=c|f

(t₁)} 3. {

f.state=R

 (t₀)}[→ f^(D)(t₀)]{

f.input=s & f.state=R

 (t₁)} 4. {

f.input=s

 (t₀)}[→ f:mR?( )(t₀)]{

true & f.state=S

 (t₁)} 5. {

f.input=s

 f.state=S

 (t₀)}[→ f:pR?( )(t₀)]        {

true & f.state=S

 (t₁)}] 6. {

g.input=s

 (t₀)}[→ g:mR?( )(t₀)]      {

true & g.input=φ & g.state=S

 (t₁)} 7. {

g.input=s

 g.state=S

 (t₀)}[→ g:pR?( )(t₀)]      {

true & g.input=φ & g.state=S

 (t₁)}] (5.20)

The above statements describe what happens at the beginning and endingof a protocol execution, and what happens when delivery signals aresensed. Lines (1) and (2) specify that in the beginning, signal c|f issent to port g and f, respectively, if the ports are ready to send out amessage. As shown lines (4) through (7) ports f and g will be ready onlyif its state is S or its input is s and the state always moves to S whendelivery signal is sensed. Immediately after the signal is sent, thestate of ports changes to R. Thus, after sending out a message they bothcannot immediately send out a second message. Similarly, line (3)describes what happens at the time of message delivery in a protocolexecution: Here, ‘→f^(D)(t₀)’ is the delivery event at port f. It beginsat time t₀ and ends at the time when f.input=s becomes true. Lines (4,5, 6 & 7) describe what happens when an already delivered signal atports f or g is later sensed. Notice, lines (6 & 7) g.input is reset toφ. Thus, a delivered signal may be sensed only once at port g. Asmentioned earlier, this resetting of g.input=φ will not occur for thesubclass of generalPorts that belong to a generalPort vector. In allcases, after sensing a signal, ports move to state S, thereby givingaccess to the parent-cell of the port to all data in virtualMemory ofthat port. Once a port is ready to send out a signal, it continues to beready till a signal is sent out, as defined in line (1) and line (2).

There is another interpretation for CommunicationEvent evaluations. TheSMS (Section 7) uses event evaluations to install instances of ALLEOPnodes in a growing causalnet of an application, while the application isrunning. This is defined below in (5.21) and (5.22). FIG. 19 shows anevent-builder cell, eb. When eb applies the evaluator, →, to aCommunicationEvent, it produces an instance of that event at a specifictime point and installs it into the causalnet. Every communicationEventhas two time points associated with it: One is the time when the eventitself occurred (this is important) and the other is the time when itsinstance is installed in a causalnet (this is not important). The use ofthese two time points is explained below.

In (5.21) and (5.22) below, [eb.f₁, eb.f₂] is a port-vector of the EventBuilder cell eb in FIG. 19; C_(i).g_(i) and D_(j).f_(j) are ports thatexchange message, 0≦i<n>0 and 0≦j<m>0. The cells C_(i) evaluateC_(i).g_(i).protocol in parallel to send message and deliver it to portsD_(j).f_(j). These protocol executions are coordinated by agents in thegroup-to-group pathway in FIG. 19. These protocol executions triggerevaluation of the communicationEvents C_(i).g_(i) ^(S)(t_(s)) and

D_(j).f_(j) ^(D)

(t_(d)), where t_(s) is the time message sending started, and t_(d) isthe time when message delivery completed. Evaluation of the aboveCommunicationEvents to install instances of these two events in thecausalnet is defined as follows:

□[ ∃(t₁<t₂)∃(t_(s) < t_(d))  {

eb.f₁:mR?( ) & eb.f₂:mR?( )

 (t₁)}   [→ (C_(i).g_(i) ^(S)(t_(s)),

D_(j).f_(j) ^(D)

 (t_(d))) (t₁)]  {

c_(i).g_(i) ^(S)(t_(s)) &

d_(i).f_(j) ^(D)

 (t_(d))

 (t₂)}] (5.21)During protocol execution, signals are sent to ports [eb.f1, eb.f₂] toinstruct the eb cell to create instances of the CommunicationEvents,C_(i).g_(i) ^(S)(t_(s)) and

D_(j).f_(j) ^(D)

(t_(d)). The way this happens is explained in Section 7. In (5.21) ebcompletes sensing of the signals received by both ports in [eb.f1,eb.f₂] at time t₁. This is also the time when eb begins its evaluationof (C_(i).g_(i) ^(S)(t_(s)),

(D_(j).f_(j) ^(D)

(t_(d))). This results in the installation of event instances(c_(i).g_(i) ^(S)(t_(s)),

d_(j).f_(j) ^(D)

(t_(d))) in the causalnet at time t₂. Here, t_(s) is the time whencoordinated signal corresponding to signals sent by C_(i).g_(i) isforwarded by an agent in the pathway, and t_(d) is the time whensynchronized delivery signals are set in all D_(j).f_(j).

□[ ∃(t₁<t₂)∃(t_(s) < t_(d))  {

eb.f₁:mR?( ) & eb.f₂:mR?( )

 (t₁)}   [→ (D_(j).f_(j) ^(S)(t_(s)),

C_(i).g_(i) ^(D)

 (t_(d))) (t₁)]  {

d_(j).f_(j) ^(S)(t_(s)) &

c_(i).g_(i) ^(D)

 (t_(d))

 (t₂)}] (5.22)(5.22) describes events installed in the causalnet for the reply messagetransmission. We will hereafter associate with communicationEventinstances only the time points at which the events occurred and not showthe time points at which the instances were installed in the causalnet.This is consistent with the way we associate time points withactionEvent instances.

Equality of Event Classes and Event Instances:

(X=Y)

(X≡Y) and X[T ₁( . . . )]=Y[T ₂( . . . )]

(X≡Y) & (T ₁( . . . )≡T ₂( . . . ))  (5.23)

(x=x)

(x=x) and x(t ₁)=x(t ₂)

(x≡x) & (t ₁ =t ₂)  (5.24)

Thus, Event classes and event instance have the status of constants;they are equal iff they are identical. However, evaluation of Event X isdifferent from evaluation of a constant. Also, as mentioned earlierevents also have the status of predicates.

Simultaneity and Parallelism: Parallel evaluations ofCommunicationEvents occur when ever multiple evaluators are used. ForCommunicationEvent evaluations described in (5.20) the following holds:

([^(E1)→ X[T₁(...)]] || [^(E2)→ Y[T₂(...)]])

(E1≠E2) (5.25) ([

^(E1)→ X(c₁.t₁)

 (c₁.t₂)] & [

^(E2)→ Y(c₂.t₁)

 (c₂.t₂)])

    [(E1≠E2) & (X≠Y) & (x≠y) & x(c₁.t₂) & y(c₂.t₂)       & c₁.t₂∈T₁(...)& c₂.t₂∈T₂(...)] (5.26)In (5.25), T₁( . . . ) and T₂( . . . ) are the two time-maps ofCommunicationEvents in two different evaluators. Both evaluationsstarted in the two evaluators at the local time points, c₁.t₁ and c₂.t₁,and were completed at c₁.t₂ and c₂.t₂, respectively, c₁.t₁<c₁.t₂ andc₂.t₁<C₂.t₂. CommunicationEvent instances x(c₁.t₂) and y(c₂.t₂) occur attime points at which evaluations were completed. It is possible that thesemi open time intervals [c₁.t₁, c₁.t₂) and [c₂.t₁, c₂.t₂), during whichthe two evaluations occurred, overlap in global time. Generally, thepairs of local time points (c₁.t₁, c₂.t₁), at which the two evaluationsstarted, and (c₁.t₂, c₂.t₂), at which evaluations terminated, would beincomparable; i.e., they may occur in any order. Parallel evaluation isthen written as (

→X

(c₁.t₂)∥

→Y

(c₂.t₂)). If the two events are synchronized or coordinated, then T₁( .. . )≡T₂( . . . ) and c₁.t₂=c₂.t₂ in global time. Parallel evaluation isthen written as, [→

(X∥Y)

(c₁.t₂=c₂.t₂)]. Similar parallel evaluations may occur also forActionEvents. The only difference is, no time-maps are associated withActionEvents, but virtual time points are associated with ActionEventclasses and time-points at which evaluations (instances) occur arespecified. Any Event class may have multiple instances occurring atdifferent times in a strictly increasing sequence of time points.

Causation: In the following, X and Y are Event subclasses. We use theevaluator symbol, →, as the causation symbol in the following sense:occurrence of an event may cause one or more other events to occur; read‘X→Y’ as ‘X causes Y’, and X^(C(X,Y))→Y as ‘X causes Y’ if conditionC(X,Y) is true:

(a) X → Y

 □[∀(t)∃(τ > 0) (X(t)

 Y(t+τ) & τ ≦ τ_(max)(X,Y))] (b) X ^(C(X,Y))→ Y

 □[∀(t)∃(τ > 0) (X(t)

     Y(t+τ) &

C(X,Y)

 (t+τ) & τ ≦ τ_(max)(X,Y))] (5.27) (c) X → φ ≡ STOP (nothing happens)(5.28)where τ_(max)(X,Y) is the maximum permissible delay between occurrencesof the two event instances.

Immediate Causation:

X→Y

[(X→Y)

∃e(X→e→Y)]  (5.29)

X→Y

∃e(X→e→Y)  (5.30)

No event may occur between X and Y in X→Y in (5.30). Thus theevaluation → is indivisible; it cannot be interrupted.

5.5. Causal Chains and Refinements

Causal Chain:

□[X→ . . . →

((X→Y)|∃(Z)(X→Z→ . . . →Y))]  (5.31)

□[(X⋄Y)

(X→Y)

(Z)((X→Z)

(Z⋄Y))]  (5.32)

Immediate-Causal Chain:

X→ . . . →Y

((X→Y)|∃(Z)(X→Z→ . . . →Y))  (5.33)

□ operator should be assumed even if it is omitted, as in (5.33). It ispossible that the causal chain (or immediate causal chain) of events ina pthread or protocol execution branches with alternates on either sideof statements (5.31) and (5.33), leading to different terminal events,as shown in (4.5), (4.6), (4.14), (4.16) and (7.4). When a fork occursin a protocol execution, the causal chain will contain parallel brancheswhich may eventually join at a single common communicationEvent, asillustrated in the diagrams in FIG. 6. This holds true for allrefinements introduced below. For simplicity we use linear immediatecausal chains in our discussions below. It should be assumed that causalchains may contain branches with alternates and/or forks in all cases.

Refinement of →:

RefinementOf(X → Y) =    [(X •→ Y)

 ∃(e)(X •→ RefinementOf(e → Y))] (5.34)A refinement of (X→Y) is an immediate-causal chain, e₁→e₂→ . . .→e_(n), such that (X→Y)=(X→e₁→e₂→ . . . →e_(n)→Y). If we useε_(i) to refer to the immediate causal chain ε_(i)=e_(i1)→e_(i2)→ . .. →e_(ik(i)) for 0≦i≦n, then the general cases would be, for n≧0,

RefinementOf[(X→(Y₀|Y₁|...|Y_(n))] =    [(X ∈₀ Y₀)|(X ∈₁ Y₁)|...|(X∈_(n−1) Y_(n))], (5.34a) RefinementOf[(X→(Y₀||Y₁ ||...|| Y_(n))] =   [(X ∈₀ Y₀) ||(X ∈₁ Y₁) ||...|| (X ∈_(n−1) Y_(n))], (5.34b)where ε_(i) for 0≦i≦n are immediate causal chains, the symbol ‘|’specifies alternates and the symbol ‘∥’ separates parallel causalchains, or any combination of (5.34a) and (5.34b).

Pthreads and protocols: The delivery events caused by a protocol arealways uniquely determined by signals exchanged during protocolexecution. A refinement of message transport from a port p to a port qhas the form (linear refinements are assumed in all statements below,only for simplicity),

p^(S)[T1(...)] → q^(D)[T2(...)] = p^(S)[T1(...)] •→ protocol •→q^(D)[T2(...)] = p^(S)[T1(...)] •→ e_(c0) •→ e_(c1) •→...•→ e_(ck) •→q^(D)[T2(...)] (5.35)This is the uninterruptible sequence of CCP and other ActionEvents inthe protocol at port p. The refinement of a pthread that is executedafter a delivered message is sensed and before a response message issent out by a cell C will have the form,

C.p:mR?(C.p^(D)[T1(...)]) •→ pthread •→ C.p^(S)[T2(...)]} = C.p:mR?(C.p^(D)[T1(...)])•→ e_(p0)•→ e_(p1) •→...•→ (5.36)  e_(pn)•→C.p^(S)[T2(...)]}This is also an uninterruptible sequence of ActionEvents. It occursduring pthread execution. The refinement of

 C₁.p:mR?(C₁.p^(D)[T1(...)]) •→ pthread •→ C₁.p^(S)[T2(...)]        •→protocol •→ C₂.q^(D)[T3(...)]} (5.37) has theform, C₁.p:mR?(C₁.p^(D)[T1(...)]) •→ e_(p0) •→ e_(p1) •→...•→ e_(pn) •→C₁.p^(S)[T2(...)]•→ e_(c0) •→ e_(c1) •→...•→ e_(ck) •→C₂.q^(D)[T3(...)]}, and is written as, C₁.p:mR?(C₁.p^(D)[T1(...)]) •→e_(p0) •→ e_(p1) •→...•→ e_(pn) •→      C₁.p^(S)[T2(...)] →(C₂.q^(D)[T3(...)|| ... )]}, (5.38)in ALLEOPs, because refinements of protocols are not shown in ALLEOPs.

Synchronization: Synchronized parallel forks occur in the following.Instances of CommunicationEvents, Z₁ and Z₂ occur simultaneously in(5.39):

[(X → Z₁[T₁(...)] || X → Z₂[T₁(...)])] = X → (Z₁ || Z₂)[T₁(...)]  

 ∀(t)∃(τ >0)([X(t)

 (Z₁(t+τ) || Z₂(t+τ))), t₁+τ ∈ T₁(...) (5.39)

Generalization of Synchronous Forks:

X→(Z₁∥Z₂∥ ∥Z_(n))[t( . . . )].  (5.40)

Coordination: Parallel coordination occurs in,

([(X[T₁(...)]|| Y[T₂(...)]) → Z[T₃(...)])

    ∀(t₁,t₂,t₃)∃(τ >0)(t₁εT₁(...) & t₂εT₂(...) & t₃εT₃(...)) &       [X(t₁) & Y(t₂)

Z(t₃ = max(t₁,t₂)+τ)    (5.41)Here, Events X and Y may occur at different incomparable times: max(t₁,t₂) is defined relative to mappings of local times to a global time.Z occurs only after both X and Y have occurred.

Generalization of Coordination: Here, Event Z[T( . . . )] occurs iff allevents X₁, X₂, . . . , X_(n) had already occurred.

(X₁[T₁( . . . )]∥X₂[T₂( . . . )]∥ . . . ∥X_(n)[T_(n)( . . . )])→Z[T( . .. )]  (5.42)

Generalization of Coordination & Synchronization: Events Z₁,Z₂, . . . ,Z_(n) all occur simultaneously after Events X₁, X₂, . . . , X_(n) haveall occurred.

(X₁[T₁( . . . )]I|| X₂[T₂( . . . )]|| . . . || X_(n)[T_(n)( . . . )]) →            (Z₁ || Z₂ || . . . || Z_(n)) [t( . . . )] (5.43)

Event Alternates: (X|Y), either X or Y occurs.

Generalized Alternates: (X₁|X₂| . . . |X_(n))  (5.44)

where each X_(i) could be a causal chain. Choices in an Event alternateexpression should always be pair wise mutually exclusive.

Guards and Polling: Guards were defined in Tables 1 and 2 and examplesof polling were presented in (2.7) through (2.10). As shown in Tables 1and 2, signal sensing changes the state of a port. This is an exceptionto the general rule that condition evaluations do not change the stateof the world. The following restriction on TICC™-Ppde operation pertainsto polling:

□[∀(Ports p)∀(Ports q)((p≠q)&(p:parent( )=q:parent( )))    

(∃(t)([•→ p:mR?( )(t)] & [•→ q:mR?( )(t)]))]  (5.45)and similarly for other guards. Thus, no cell may start or finishpolling two of its ports simultaneously. There is no parallelism or timesliced concurrency with in a cell. All interrupts are programmedinterrupts that do not violate the requirement of transactioncompletion. Once polling of ports begin in a polling cycle of a cell,one of the following seven possible outcomes should occur at each port:(i) the port is skipped because there is no message; or (ii) the cellwaits for a message and then processes it as per items (v) and (vi) or(vii) below; or (iii) In the case of a port-vector the cell performs (v)and (vi) or (vii) if there is a message at all the ports in theport-vector, else skips the port-vector; (iv) In the case ofport-alternates the cell performs (v) and (vi) or (vii) if there is amessage in any one of the alternate ports, else skips theport-alternates; (v) if there is a message at a port (or port-vector),the cell schedules the port (or port-vector) for service by entering itinto a sortedPortsList of the cell; or (vi) the cell services the port(or port-vector) immediately after sensing the message; or (vii) aprogrammed suspension of service occurs and service resumes in anensuing polling cycle.

Consistency of world state: Every world state W(t) represents the stateof a computation at time t. At any time point, t, the world state W(t)is consistent. The proof system maintains and updates world states atpostulated time points during ECT-evaluations. If it detects acontradiction between a CTL-assertion and the ECTs during ECT-evaluation(illustrated in Section 6) then the assertion is not valid. Suchcontradictions would indicate design or implementation errors.Contradictions with ALLEOPs encountered during causalnet generation bySMS indicate errors in system operation.

Condition Migration over →: We refer to the format, ‘→C?(){X}’, where Xis a Communication or Action Event, as ALLEOP format, and format

{

pre-C?() & C?()

(t₀)}[→X(t₀)]

{

X.output & pst-C?()

(t₁)}, t₁≦t₀+τ_(max)(X),

as the trace format. The latter describes the semantics of C?(){X}.Execution is between the time points in the semi-closed interval[t₀,t₁), and τ_(max)(X) is the maximum permissible delay. In thefollowing it has been assumed that condition evaluation will not changethe world, and Action is evaluated in the same world at time t₀ in whichthe pre-conditions become true, guards being excepted from this rule.The context x and y below in (5.46) are either a cell C or a port C.p.All condition checking and Action evaluations take place in the contextof a single cell, C.x:names()(t)⊂C:names()(t) holds. This context willinclude in it local code execution stacks of variables maintained by anevaluator during a method evaluation.

[∃(t₁)∃(t₂)∃(τ₁>0)∃(τ₂>0)  {

x.A₁:pre-C₁?( ) & x:C?( )

(t₁)}    [•→ x:A₁( )(t₁)] {

A₁:output:C?( ) & x.A₁:pst-C₁?( ) )(t₁+τ₁)}  {

y.A₂:pre-C₂?( ) & y:C?( ) )(t₂)}    [•→ y:A₂( )(t₂)] {

A₂:output:C?( ) & y.A₂:pst-C₂?( ) )(t₂+τ₂)})  

((t₂= t₁+τ₁) & (x.A₁:pst-C₁?( )

y.A₂:pre-C₂?( ))(t₂))] (5.46)As mentioned earlier, an Action evaluation is undefined if itsx:pre-C₁?() is false and is skipped if x:C?() is false. While executingtwo successive Actions x:A₁() and y:A₂() linked by →, execution ofy:A₂() begins at the same time as execution of x:A₁() terminates, and inaddition, the world state in which the post-condition of x.A₁() is true,logically implies the pre-condition of y:A₂(). There is usually a smalldelay between the time when A₁ terminates and the time when A₂ starts.But during this delay the world of cell C does not change, since noother action may occur in cell C between two such actions, and actionsoccurring in other cells cannot affect the state of cell C because ofcell isolation (section 3.2). Thus, this delay is ignored.

In polling cycles we used specifications of the form,(C.f[i]:mR?()→C.f[j]:mR?()) for i≠j. This is interpreted as(C.f[i]:mR?()→ . . . →C.f[j]:mR?()) in the following sense:

∃(t₀<t₁<t₂<t₃<t₄)  ({C.f[i]:mR?( )(t₀) /*begins*/ &

C.f[i]:mR?( )

(t₁)/*ends*/}   [•→ C.f[i]:tip( )(t₁) /*begins*/][(•→ C.f[i]:tip( ))(t₂)/*ends*/  {C.f[j]:mR?( )(t₂) /*begins*/ &

C.f[j]:mR?( )

(t₃) /*ends*/}  [•→ C.f[j]:tip( )(t₃)/*begins*/][(•→ C.f[j]:tip())(t₄)/*ends*/]) (5.47)In other words, servicing of C.f[i] and C.f[j] occur in the semi-closedintervals, [t₁, t₂) and [t₃,t₄) such that ([t₁,t₂)∩[t₃,t₄))=φ, with therestriction, C.f[j]:mR?()(t₂), i.e. evaluation of C.f[j]:mR?() begins attime point t₂ when [

→C.f[i]:tip()

] ends. Here, servicing of C.f[j] occurs only if C.f[i]:mR?()(t₀)evaluates to true, else the port is skipped and polling proceedsimmediately to C.f[j]. Thus, polling cycles only specify the order ofpolling, but not the order in which polled ports are serviced. Paralleltriggering of TIPs that follow each other in different cells because ofcommunications was described in the examples in Section 2; here, theonly requirement is that conditions that characterize messages at thetime they are sent remain invariant until they are delivered and thedelivered messages are sensed and used.

Let us now proceed to consider examples that illustrate simpleALLEOP-proofs. In all proofs we assume that implementations of allpthreads and conditions would have been already individually verified.This is possible since pthreads are mutually independent, dependentpthreads are jointly verified, and conditions are always local to acell. We begin with a generalized version of the “Ornamental GardenProblem” introduced in [Magee & Kramer, 13]. Formal ALLEOP-proofs arepresented for this example, for “mutual exclusion” and “conditionsynchronization” (terms used in [Magee & Kramer, 13]). The solutionapplies also for the “Car Park” problem in [Magee & Kramer, 13].

6. Examples with ALLEOP-Proofs

6.1. Ornamental Garden: Mutual Exclusion and Condition Synchronization

Our objective here is to display the structure of ECT-networks and showhow they are used by the system to generate proofs. See Maggie & Kramer,[13] for the FSP specification for the Ornamental Garden problem. Theproblem is the following: An ornamental garden park has several gates,each with a turnstile. As in Magee and Kramer we assume two entrancegates at two ends of the park, but unlike Magee and Kramer we alsoassume two exit gates. Gates are opened when the park is opened, andclosed when the park is closed after all people who entered the park hadleft. At any time the park is open, people are allowed to enter throughany entrance gate, and exit through any exit gate. It is necessary tokeep an accurate count of number of people who are in the garden at anytime, and never allow that number to exceed a preset max.

The TICC™-network is shown in FIG. 10. It has two entrance turnstiles,Et[0] and Et[1], and two exit turnstiles, Xt[0] and Xt[1]. There is oneenvironment, E, which opens and closes the gates of the park based onexternal interrupts. There is one counter. We assume, when a personarrives at entrance or exit turnstiles, Et[j] or Xt[j], for j=0,1,sensors Se[j] and Sx[j] detect persons at turnstiles. Each turnstiletogether with its sensor is an encapsulated cell. They are shownseparately in FIG. 10 for convenience. On detecting a person, thesensors signal the ports Et[j].f_(t) or Xt[j].f_(t), for j=0,1 throughtheir respective generalPorts, Se[j].g and Sx[j].g. Pathways, Se[j].g

Et[j].f_(t) and Sx[j].g

Xt[j].f_(t) are internal to the encapsulation. Sensors signal thefunctionPorts f_(t) (t for turnstile) through these hidden pathways.

Predicates, Et[j]:personEntering?() and Xt[j]:personLeaving?() becometrue when Et[j] and Xt[j], respectively, detect signals at portsEt[j].f_(t) and Xt[j].f_(t). See Appendix I for definitions of thesepredicates. The following TIPs are executed by the sensors, internal tothe encapsulation, when they detect persons:

Se[j].g:TIP( ) =   Se[j].f:personAtGate?( ){Se[j].g:pR?( )*{Se.g[j]:s();}}   (6.1a) Sx[j].g:TIP( ) =   Sx[j].f:personAtGate?( ){Sx[j].g:pR?()*{Sx[j].g:s( );}}   (6.1b)The counter has five functionPorts, C.f[j], 0≦j<5. They are used asfollows:

For j=0,1: On sensing the signals at ports Et[j].f_(t), the turnstilessignal the counter through pathways Et[j].g

C.f[j] (see FIG. 10). When counter C senses the signal at C.f[j] for0≦j≦1, it does the following: (i) C increments the count by one, ifcounter.count<max and signals back via C.f[j]

Et[j].g to inform Et[j] that the person at the gate may enter. Thisresponse also acts as acknowledgement for the signal that C.f[j]received from Et[j].g and the transaction gets completed. On receipt ofsignal at Et[j].g, the turnstile unlocks and the person at Et[j].f_(t)is let into the garden. (ii) If (counter.count≧max) then C signals viaC.g[j]

Et[j].f informing Et[j] that the garden is full; on receipt of signal atEt[j].f, the turnstile displays “PARK FULL” without unlocking theturnstile. The person then leaves the gate. In this case, C sends backan acknowledgement to the signal received from Et[j].g at its portC.f[j] after receiving the response from Et[j].f, thereby completing thetransaction between both pairs of ports, [Et[j].g, C.f[j]] and [Et[j].f,C.g[j]].

In order to do one of the two alternate actions, either allowing theperson to enter or not enter, Et[j] performs synchronousnon-deterministic polling, ∃(p)(p=(Et[j].g|Et[j] f))p:mR?())*, and thuswaits for response from the counter at one of these two ports, andresponds accordingly.

For j=2, 3: The exit turnstiles, Xt[j].g for j=0,1, signal the countervia Xt[j].g

C.f[j+2]. On sensing signal at C.f[j+2] the counter decrements the countby one and signals back via C.f[j+2]

Xt[j].g, in order to unlock the turnstile and let the person at leave;Xt[j] waits at Xt[j].g for this response, by performing synchronouspolling, Xt[j].g:mR?()*.

For j=4, the port C.f[4] is used by the counter to receive and respondto requests from the display unit to send the current value ofcounter.count. The display unit sends the request for count based on anexternal interrupt from a user (see FIG. 10).

Multiple people may enter and leave simultaneously, in parallel, usingmultiple turnstiles. However, each turnstile will allow only one personto enter or leave at a time. The program is self-scheduling,self-coordinating and self-synchronizing. The TICC™-network and TIPsdetermine signal exchanges and execution control structure. It should beclear, the OG-solution in Appendix I applies also to the Car-Parkexample defined in [Magee & Kramer, 13], with multiple Car-Parkentrances and exits, with the difference, parking fee has to be paidbefore a car leaves.

The time taken for signal exchanges and counting should be less than amillisecond assuming 5 kilometers long signal transmission lines with 1Gigabits/sec signal transmission capacity, using 2 gigahertz CPUs. Thus,one may have practically unlimited number of entrance and exitturnstiles. The CIPs, ALLEOPs and traces for the TICC™-Ppdeimplementation, based on this network, are presented in Appendix I. Werefer to this as the OG-Solution.

To complete the implementation shown in Appendix I, one has to definethe following: personAtGate, personEntering?(), personLeaving?(),denyEntry(), letPersonIn(), letPersonLeave(), personInPark() anddisplayCount(). With that the ALLEOPs and traces in Appendix I wouldmodel the completed implementation. The implementation does not requiremonitors, semaphores, rendezvous [Hoare, 10,12][Dijkstra, 23,24], locks,schedulers or any other synchronization or coordination controlprimitives.

It should be clear that in this organization no two counter activitiesinvoked by the turnstiles will interfere with each other, since thecounter services a second functionPort only after completing the serviceat the first one. It should also be clear that the number of people inthe park could never exceed max, since permission to enter is grantedonly if (counter.count<max) before the counter is incremented. We wantto formally prove these starting from implementation specifications, inorder to show that the implementation satisfies the requirements. Inparticular, we want to prove the following:

Stmt 1) Every person entering the garden is added to the count exactlyonce;

Stmt 2) Every person leaving the garden is subtracted from the countexactly once;

Stmt 3) Total number of people in the garden never exceeds max.

User defines the following interpretations for Stmt 1 and Stmt 2 above,as CTL-statements:

Events in CTL-statements are specified either by predicates or actions.Quantifications in CTL-statements (6.2) and (6.3) below range overpostulated time-points and events that occur in the statements.

  □[∃(ctl.t₀ < ctl.t₁ < ctl.t₂ < ctl.t₃) &    (ctl.t₄ < ctl.t₅ < ctl.t₆< ctl.t₇) &    ((ctl.t₂ < ctl.t₅ ) | (ctl.t₆ < ctl.t₂)) ∃!(A1)(A1instanceOf counter++)∃!(A2)(A2 instanceOf counter−−)   EnteringGarden-CountedOnce =      [{

personEntering?( )

(ctl.t₀)}         →...→ [

•→ A1(ctl.t₁)/*begins*/

(ctl.t₂)/*ends*/])         →...→ {personInPark?( )(ctl.t₃)}]   & (6.2)   LeavingGarden-CountedOnce =      [{

personLeaving?( )

(ctl.t₄)}         →...→ [

•→ A₂(ctl.t₅) /*begins*/

(ctl.t₆)/*ends*/]         →...→ {

personInpark?( )(ctl.t₇)}]] (6.3)The following definitions are reproduced here from Appendix I, forconvenience:

Et[j]:personEntering?( )    

Et[j].f_(t):mR?(

Et[j].f_(t) ^(D)

[T(Se[j].g,1)]) (I.4) Xt[j]:personLeaving?( )    

Xt[j].f_(t):mR?(

Xt[j].f_(t) ^(D)

[T(Sx[j].g,1)]) (I.11)

In the CTL statement (6.2), ctl.t₂ is the time at which the invocationof counter instance A1 terminates and in (6.3), ctl.t₅ is the time wheninvocation of A2 begins. The restriction (ctl.t₂<ctl.t₅) appears as oneof the alternates in the existential quantifications on top of thestatements: it asserts that counter invocation in (6.3) should come onlyafter the termination of counter invocation in (6.2). Similarly, theother alternative, (ctl.t₆<ctl.t₂), asserts the other possibility,namely invocation in (6.2) should come after termination of invocationin (6.3). In both cases, the semi-closed intervals during which thecounter instances are active in the two statements, namely [ctl.t₁,ctl.t₂) and [ctl.t₅, ctl.t₆), should be non-overlapping.Quantifications, ∃!(A1) (A1 instanceOf counter++) ∃!(A2) (A2 instanceOfcounter−−), assert that in each statement there is only one uniqueoccurrence of counter instance.

We have here assumed that each invocation of counter++increments thecount by 1 and each invocation of counter−− decrements the count by 1.Thus, (6.2) and (6.3) assert, a person at gate should be allowed toenter the park only after the counter had been incremented by 1, exactlyonce, and allowed to leave the park only after the counter had beendecremented by 1, exactly once and the two invocations of the countershould not overlap. The starting and ending events in (6.2) and (6.3)are:

Starting Events Ending Events In (6.2):

personEntering?( )

(ctl.t₀) personInPark?( )(ctl.t₃) In (6.3):

personLeaving?( )

(ctl.t₄)

personInPark?( ) (ctl.t₇)

Notice, the pairs of time points (ctl.t₀, ctl.t₄) at which startingevents terminate in (6.2) and (6.3) are incomparable. So also, the timepoints (ctl.t₃, ctl.t₇) at which ending events begin are incomparable.They occur in parallel. Thus, persons may enter and exit simultaneouslyor in any order. For this example, replacing the second ellipse, → . . .→, in (6.2) and (6.3) by ⋄ will not change the meaning of thestatements, since in each case there is only one way of reaching theending event from the starting event. The problem to prove is,

Traces├

EnteringGarden-CountedOnce & LeavingGarden-CountedOnce  (6.4)

where Traces is the set of all traces for the implementation, and ├ isthe logical consequence relation. At this point, the CTL assertionsabove do not state how many entrances and exits are in the garden. Thisis something to be discovered by analyzing the implementation.

6.1.1. The ECT-Network for the OG-Solution

The network in Table 5 shows interactions between the various ECT-blocksBlock(5a) through Block(5g). Block(5a) though Block(5g) are shown inTable 5.1 though Table 5.3. Each block contains a list of events,numbered in the order they occur, with virtual time points associatedwith each event. Thus, the sensor block, Block(5a), shown in Table 5,whose details are shown in Table 5.1, has seven events. These are theevents that occur in the port-trace, Se[j].f:port-Trace (se[j].t₀), asindicated by the header, Se[j].f:port-ECT(se[j].t₀) in Block(5a) inTable 5 and Table 5.1. The task performed by the events in this block issummarized inside Block(5a) in Table 5; similarly with the other blocksin Table 5.

Block(5a) activates Block(5b) through a signal exchange, shown by asolid directed branch marked “personEntering” in Table 5 linking the twoblocks. Here, the sensor Se[j] (Block(5a)) sends a signal to entrancegate Et[j] (Block(5b)) indicating that a person is entering. We refer tothis as parallel activation because Se[j] and Et[j] run in parallel.Details of this communication are shown in Table 5.1: Block(5a) rows 4and 5, and Block(5b) rows 1 and 2 in Table 5.2. We use the convention,(5a,4-5) to refer to events in the rows 4 through 5 block 5a. Areference like (5a,3) will simply refer to the event in row 3 of block5a. Thus, the comment “to (5b,2)” in row 5 of Block(5a) in Table 5.1indicates that the signal is being sent to row 2 of Block(5b) in Table5.2. In all blocks, signal delivery event and signal sensing event aredeclared separately: thus delivery is to (5b,1) sensing occurs in(5b,2). This is because delivery and sensing may not both happensynchronously, unless a port is waiting for the signal at the timesignal was delivered.

Always, signal sensing requires coincidence of two activations: (i)parallel activation through signal delivery and (ii) sequentialactivation through flow of execution control. A signal delivered to aport is sensed only when that port is polled by its parent cell. Allparallel activations require coincidence of both activations. Reader mayverify that this holds true in Table 5, where sequential activationsbetween the blocks are shown by directed branches with broken lines andparallel activations by solid directed branches. The ellipse “→ . . . →”occurs in a parallel activation branch, for example in the branch on theleft going from Block(5b) (Et[j]) to Block(5e) (Counter) marked “askcounter, can enter?”, indicates, sensing may not occur at the time ofsignal delivery. Here sequential activation of the port Et[j].f_(t) iscontrolled by the polling cycle of the counter, as indicated by branchwith broken lines going into Block(5e) from bottom left of Table 5,marked

(1). “∃(i)

C.f[i]:port-ECT(cf[i].t₀)

”

and the branches with broken lines going out of the bottom center ofBlock(5e) in Table 5, marked

(2). “∃(i)(C.f[i]:port-ECT(cf[i].t₀))”.

The angle brackets in (1) above indicate that activation is at the endof

C.f[i]:port-ECT(cf[i] t₀)

execution and absence of angle brackets in (2) indicate that activationbegins the port-ECT. It is possible that i=j, since it is possible thatthe counter services a second person entering through the same gateEt[j] in the next polling cycle after having served the first person inthe previous polling cycle, with no intervening services at any othergate.

In all other parallel activations in Table 5, there are no ellipses,because ports to which signals are being sent would be waiting for thesignals in every case, and sense the signal as soon as it is delivered.Inside each block, sequential activations occur in the order eventsoccur in the block.

When the turnstile Et[j] senses the personEntering by sensing deliverysignal at its port Et[j].f_(t), shown in (5b,2) of Table 5B, Et[j]begins to respond to the received message. It asks the counter for entrypermit and depending on the response received from the counter, eitherlets the person enter or displays sign, “PARK FULL”. It is worthnoticing the sequential branching at the bottom of Block(5b) in Table 5.This occurs as a result of non-deterministic polling shown in (5b,5) inTable 5B. The system picks out from the ETC-networks in Tables 5.1through 5.3 and Tables 6.1 and 6.2 events needed to prove theCTL-assertions (6.2) and (6.3), as described in the subsection 6.1.2.

Summary: Sequential activations between ECT blocks in Tables I and IIrepresent Execution orderings of events in the network. These aredetermined by the polling cycles and the order in which TIPs in cellsare executed. We refer to sequential ordering of events inside each ECTblock as causal ordering. They show event occurrences caused by TIPexecutions. The network shows the series/parallel composition ofport-ECTs that are consistent with port-ALLEOPs and polling cycledefinitions in Appendix I.

6.1.2. Structure of ALLEOP-proofs

The proof system searches the ECT-network (i) to identify matchingcorrespondences between time points postulated in the CTL-assertions andthe virtual time points in the ECT-blocks; (ii) to find causal chains inthe ECT-network from starting events in CTL-assertions to ending events;and (iii) analyze the causal chains to verify that claims inCTL-assertions are satisfied by the causal chains. In this example, thesearches are simple. They do not show complexities that may arise due tomultiple choice points, multiple parallel activations (forks) anditerations. Some of the complexities that appear in such searches arisein the DP-Solution in Section 6.4.

The proof system displays the following matching time points betweenthose specified in the CTL-statements and the virtual time points in theECTs in Tables 5.1 through 5.3 and Tables 6.1 and 6.2. They are shownbelow:

Matching time points for statement (6.2), for j = 0,1 ctl.t₀ = et[j].t₀:Et[j]:personEntering?( ); (5b,3) Starting Events ctl.t₁ = cf[j].t₂: [•→counter++] begins; (5f,2) ctl.t₂ = cf[j].t₃: [•→ counter++] ends; (5f,3)ctl.t₃ = et[j].t₂: Et[j]:personInPark?( ); (5c,4) ending Events (6.5)Matching time points for statement (6.3), for j = 0,1 ctl.t₄ = xt[j].t₀:Xt[j]:personLeaving?( ); (6b,3) starting Events ctl.t₅ = cf[j+2].t₂: [•→counter−−] begins; (6d,3) ctl.t₆ =cf[j+2].t₃: [•→ counter−−] ends;(6d,4) ctl.t₇ = xt[j].t₂:

Xt[j]:personInPark?( ); (6c,4) Ending Events (6.6)

There are two possible starting/ending events, one for j=0 and the otherfor j=1, as shown in (6.5) and (6.6) that match with the events in (6.2)and (6.3), respectively. The system displays the following causal chainsbetween starting and ending events in the ECTs that correspond to (6.5)and (6.6) for j=0,1. The causal chain is put in trace format.

For the Entrance Gate Et[j]: [{

Se[j].personEntering

(se[j].t₁)}[•→ Se[j].g^(S)(se[j].t₁)]  

Et[j].f_(t):mR?(

Et[j].f_(t) ^(D)

(e[j]ft.t₀=se[j].t₂))

(e[j]ft.t₁)}   [•→ Et[j].g^(S)(e[j]g.t₀)] [→

C.f[j]^(D)

(e[j]g.t₁=cf[j].t₀)]      //parallel activation begins here      ||[•→...•→ {

C.f[j]:mR?(

Et[j].f_(t) ^(D)

(

C.f[j]^(D)

(e[j]g.t₁))}         {

counter.count < max

(cf[j].t₂)}           [•→ counter++(cf[j].t₂)]         {

counter.count ≦ max

(cf[j].t₃)}           [•→ C.f[j]^(S)(cf[j].t₃)] •→           [

→ Et[j].g^(D)

(cf[j].t₄ = e[j]g.t₂)] •→...•→]       // continues with the next port ofthe counter with a service request.  //activity resumes in Et[j].inresponse to signal from c,f[j].  {

Et[j].g:mR?(

→ Et[j].g^(D)

(cf[j].t₄ = e[j]g.t₂))*

(e[j]g.t₂)}   [•→ Et[j].g:letPersonIn( )(et[j].t₁)] {Et[j]:personInPark?( )(et[j].t₂)}   [•→ Et[j].f_(t) ^(S)(et[j].t₁ <e[j]ft.t₂)]   [

→ Se[j].g^(D)

(e[j]ft.t₃)]] (6.7)Here we ignore the case where entry is denied; the CTL-statement doesnot call for it.

For the Exit Gate Xt[j]:  [{

Sx[j]:personLeaving

(sx[j].t₁)}[•→ Sx.g^(S)(sx[j]g.t₁)]  

Xt[j].f_(t):mR?(

Xt[j].f_(t) ^(D)

(x[j]ft.t₀=sx[j].t₂))

(x[j]ft.t₁)}    [•→ Xt[j].g^(S)(x[j]g.t₀)][→

C.f[j+2]^(D)

(x[j]g.t₁=cf[j+2].t₀)]      || [•→...•→ {$$C.f[j+2]:mR?()$$(cf[j+2].t₁)}             [•→ counter−−(cf[j+2].t₂)]           {

counter.count < max

(cf[j+2].t₃)}             [•→ C.f[j+2]^(S)(cf[j+2].t₃)]             [

→ Xt[j].g^(D)

(cf[j].t₄ = x[j]g.t₂)]]  {

Xt[j].g:mR?(

→ Xt[j].g^(D)

(cf[j].t₄ = x[j]g.t₂))*

(x[j]g.t₂)}      [•→ Xt[j].g:letPersonOut( )(x[j]g.t₂)]  {

Xt[j]:personInPark?( )

(xt[j].t₁)}      [•→ Xt[j].f_(t) ^(S)(x[j]g.t₃ < x[j]ft.t₁)]      [(

→ Sx[j].g^(D)

x[j]ft.t₂)] (6.8)

As the system constructs traces it marks the events in ECT-networks thatoccur in the traces, and keeps track of the events and their virtualtime points. We refer to this process as symbolic evaluation ofCTL-statements over ECT-networks. Reader may verify that traces (6.7)and (6.8) follow from Tables 5.1-5.3 and 6.1-6.2. During traceconstruction conditions are enclosed in chain brackets gatheringtogether all conditions that occur at the same virtual time point intoone conjunction. Action events are enclosed with in square brackets withthe evaluation sign, →.

At this point, user notices that there is incomplete specification ofrequirements. In (6.7) the counter is active during the semi-closedintervals, [cf[j].t₂, cf[j].t₃) for j=0,1. In (6.8) it is active duringthe intervals, [cf[j+2].t₂, cf[j+2].t₃). It has not been specified thatnon-intersection of time periods during which the counter is active,should hold also for the intervals [cf[j].t₂, cf[j].t₃) for j=0,1 and[cf[j+2].t₂, cf[j+2].t₃) also for j=0,1. User clarifies the situationhere by specifying that it should hold for all j, at both entrance andexit turnstiles. System has to now analyze the traces in (6.7) and (6.8)to verify that the updated CTL-assertions (6.2) and (6.3) hold true forall j, j=0, 1 both for entrance and exit gates.

There are three general requirements that should be satisfied by allECT-networks in order to guarantee progress:

General Requirements to be satisfied by all ECT-networks:

-   -   GR-1. The time points postulated in CTL-statements should have        matching time points in traces.    -   GR-2. Every port receiving a delivery signal should have two        activations: one is sequential activation and the other is        parallel activation.    -   GR-3. Every port with synchronous polling, whether polled in a        polling cycle or polled in an embedded TIP, should have a signal        delivered to it eventually through parallel activation.

All the above three requirements are satisfied for the networks inTables I and II. In this example, there are two additional requirements:(a) the counting event should occur only once in each causal chain and(b) no two counting invocations should overlap.⁴ The immediate causalchains of events in (6.7) and (6.8) indicate that for ports C.f[j],0≦j<4, instances of either counter++ or counter−− occur only once ineach causal chain. This satisfies requirement (a). System notices thatrequirement (b) is also satisfied. This follows from the sequentialactivations from “∃(i)C.f[i] . . . ” statements (1) and (2) given above.For i=4 the counter responds to a request from the display unit forcounter.count, and this does not invoke counting by the counter. Thus,for C.f[j], 0≦j<4, a second invocation of counting by the counter occursonly after the first invocation has terminated. Thus intervals duringwhich counter is counting do not overlap. This completes the proof forStmt 1 and Stmt 2, as updated by the user. ⁴ Even when counter appearsonly once in each causal chain it is possible for two counterinvocations to overlap because of parallel executions of causal chains.

We validate Stmt 3 by proving that the total number of people in thepark is always less than or equal to max. This corresponds to conditionsynchronization in Maggie & Kramer, [13]. This is a NFSP-proof andrequires induction of the following kind:

Basis:  counter.count = 0 ≦ max. Induction Hypothesis:  counter.count =N ≦ max. Ind. Step: [(Et[0]:personInPark?( )

Et[1]:personInPark?( ))

         counter.count ≦ max) &        (

Xt[0]:personInPark?        ( )

Xt[1]:personInPark?( ))]))

         counter.count ≦ max)] (6.9)User guides the system by providing the following CTL-assertions toprove the induction step:

[∀(i,j)(0≦j≦1)∃(e[j].t₀ < e[j].t₁)∃(x[j]t₀ < x[j].t₁)  [{

Et[j]:personEntering?( )

(e[j].t₀)} →...→          [

•→ Et[j].g:letPersonIn( )

(e[j].t₁)]    {

Et[j]:personInPark & counter.count≦ max

(e[j].t₁)}] & (6.10)   [{

Xt[j]:personLeaving?( )

(x[i].t₀)} →...→          [

•→ Xt[j].g:letPersonOut( )

(x[i].t₁)]   {

Xt[j]:personInPark & counter.count ≦ max

(x[i].t₁)}]] (6.11)

System validates these by using definitions of personEntering?() andpersonLeaving?() given in Appendix I and evaluating (6.10) and (6.11)over the ECTs in Tables 5.1 through 5.3 and 6.1 through 6.2 for allpossible orderings of pairs of turnstiles, since the starting and endingtime points in each pair, (e[j].t₀<e[j].t₁) and (x[i].t₀<x[i].t₁) for0≦j≦1, are incomparable. For example, after a person at gate Et[0].f_(t)is let in, before the person enters the garden it is quite possibleanother person at gate Et[1].f_(t) was also let in, and this secondperson may actually enter the garden before the first person, since thetimes at which persons enter and leave the garden are incomparable. Inthe mean time it is also possible that other persons left the garden. Inwhich ever order the persons enter or leave the garden,counter.count≦max, holds true after persons at gates Et[j].f_(t) andXt[j].f_(t) enter or leave the garden. This is confirmed by the causalchains (6.7) and (6.8). One may install as many entrance and exit gatesas one wants; induction will still hold. Proofs by induction requireuser guidance. It should be clear that the system organizes informationin traces and polling cycles in to a network of ECT-blocks in a formthat is convenient for finding time points that match with those ingiven CTL-statements, and build traces that match the starting andending events in the CTL-statements. Causal chains identified inECT-networks are easily transformed to trace formats.

6.1.3. Comments

The claims proven here are properties of the implementation sinceALLEOPs and traces were automatically generated from the implementation.It may be noted, as controls transfer from one cell to another, symbolicevaluation of CTL-statements over the ECTs may be done in parallel,since we may have a CPU assigned to each cell. In this example the ECTsare simple, and parallel evaluation is not needed. Only sequentialcompositions occur here, since for each entry and exit, the turnstilewaits until the counter has completed its task and servicing of eachentry and exit through any one gate is done sequentially by the counter.The only logical inferences needed here were for the incorporation ofdefinitions in (I.4) and (I.11) given above. Since pthreads are pairwise independent and may be proven correct independently provingCTL-statements will only involve chasing causal sequences inECT-networks of implementations, making propositional inferences to makeselections at choice points, if needed, and analysis of causal chains toverity that conditions in given CTL-assertions are satisfied.

Causal chains that satisfy CTL-statements validate those statements. Ifa CTL-statement is not valid, this proof method may provide a counterexample. If an ending event is not reachable, and the ALLEOP is afinite-ALLEOP then proof will terminate with a counter example. Fornon-finite-ALLEOPs, proofs may not terminate; user intervention may benecessary. After finding the needed causal chains, the system analyzessequential and parallel activations to ascertain mutual exclusionproperties and partial orderings of events. Proof method is interactive.At each stage of the proof system presents its findings to users andgives opportunities for users either to modify given CTL-statementsbased on the findings, or provide new assertions that may guide proofsearch. In this example identification of matching time points andcausal chains were simple. A more complicated proof, involving trackingof states of cells, occurs in the DP-solution in Section 6.4. In allcases, user has the responsibility to choose the set of CTL-statementswhose validity verifies the correctness of an implementation, asdiscussed in Section 6.5. For complex implementations, this may be anon-trivial problem.

This example used only point-to-point signal exchanges withoutvirtualMemories. The remaining examples use virtualMemories in theirpathways. So we introduce first the structure of virtualMemory andoperations associated with it.

6.2. Structure of VirtualMemories

FIG. 11 shows a schematic diagram of a virtualMemory. It has fourcomponents: SP for scratchpad, E for executionMemory, W for writeMemoryand R for readMemory. The executionMemory holds pthreads, data andprovides execution environment for them. We assume that each item ofdata in the execution memory will be flagged with a key referring to itsidentity in a main memory or a database, if there is one. If cells in acell-group use the same virtualMemory, M, then each cell in the groupshould have a port which belongs to a port-group, and all ports in thatport-group should be tuned to the same agent attached to M. Cells insuch cell-groups may use the scratchpad SP of M to exchange data duringpthread executions in the environment provided by the executionMemory ofM. Data from a database or a main memory may be shared by a cell-grouponly after they have been copied into virtualMemories.

The writeMemory holds the message that is sent out and the readMemoryholds the message that is delivered. Read and write memories areswitched before the message is delivered by the agent that delivers themessage. Thus every recipient reads its input message from thereadMemory. A port p may forward the message in its readMemory to a portq, to which it is connected by a pathway, by using the forward command,p:f(), instead of the send command p:s(). If a forward command is used,then the read and write memories are not switched. The forward commandis used in the DP-solution (Dining Philosophers) presented in Section6.4. Protocol for distinguishing between send/forward commands isdescribed in Section 7.

As mentioned earlier, each port p is tuned to a virtualMemory, M, bybeing connected through a branch to an agent attached to M.“VirtualMemory of p” refers to the virtualMemory p.vM=M that has been sotuned to p. We write p.rd, p.wr, p.sp and p.ex to, respectively, referto the read, write, scratchpad and execution memories of p.vM. We writep.wr:wr(msg) to write a blank instance of the message subclass, msg,(called the container for msg) into the writeMemory of M, may be withsome default data values. We use p.rd:wr(msg) to write a container formsg into the readMemory of p.vM; similarly for other components of M. Wewrite p.rd:msg()=p:msg(), and p.wr:msg() to, respectively, refer to themessages in the read and write memories of M. We use p:make (msg,[<dataSpecifications>]) to write an instance of msg with the specifieddata into the writeMemory of p, if a container is not already present inthe virtualMemory. If a container is present in the virtualMemory, thenthe make command fills it with the specified data; p.rd:make(msg,[<dataSpecifications>]) does the same for the readMemory. These make andwrite methods are assumed to be defined in theRead/Write/Scratchpad/Execution Memory components of the VirtualMemory.

In most applications, containers for needed message subclasses areinstalled into virtualMemories at the time of initialization. Thus,normally only the make command is used. Compiled codes for messagesubclasses and methods defined in them, are held in the executionMemoryof the virtualMemory. Thus, all methods and data installed in messagesubclasses in virtualMemories will be available to cells whose ports aretuned to those virtualMemories, when those ports are in state S. Morethan one virtualMemory may contain codes for the same message subclass.

We use p:msg():empty?() to check whether the message in the readMemoryof port p is empty, i.e. does not contain any data and usep.wr:msg():empty?() to check the same for the message in the writeMemoryof port p. Similarly, p:msg().attribute:empty?() andp.wr:msg().attribute:empty?() are used to check whether the specifiedattribute of the messages is empty in read and write memories of p.vM.We use, p.rd:empty?() and p.wr:empty?() to check whether the indicatedmemories are empty; i.e. no containers are present. We use p.vM:clear()to clear the contents of all memories of p.vM. Similarly, p.rd:clear()and p.wr:clear() to clear the read or write memories of p.vM,respectively. Similar, assertions are defined for the scratchpad andexecution memories as well.

FIG. 19 describes the structure of a group-to-group pathway connectingports in a generalPort group G to ports in the functionPort group F. Allparent-cells of ports in a port-group in this figure, use the samevirtualMemory, M, shown in the figure. Each cell in such a cell-groupthat uses the virtualMemory M, may read data in the memory, only when ithas access to it. Access is controlled by the ports in the port-group.At any given time, either parent-cells of ports in group G access M, orparent-cells of ports in group F access M; both of them cannot access Msimultaneously. Parent-cells of ports belonging to any port-group tunedto a virtualMemory, M, may simultaneously execute pthreads in theexecution memory of M, accessing and using commonly shared data andpthreads.

Coordination of such simultaneous parallel executions by parent-cells ofports in port-groups using the same virtualMemory M is facilitated bythe following: (i) facilities for simultaneous read access to shareddata in the virtualMemory, (ii) facilities to use pthread-locks whereneeded to coordinate data updates and (iii) facilities to communicatethrough the shared scratchpad memory during parallel executions, inorder to coordinate computations. When pthread-locks are used they wouldapply only to the cells in the cell-group that use M. The possibilityfor memory contention is limited by limiting the number of cells incell-groups. We estimate, in practice the number of cells in acell-group is not likely to exceed 8 or 16. To prevent data overwritingand to protect data, the area of virtualMemory into which a cell in acell-group may write is restricted. Ports in a port-group that are tunedto the same virtualMemory may hold addresses of non-overlapping memoryareas into which parent-cells of those ports may write data. Thesefacilities may be used to effectively minimize memory contention. Wepresent in Section 8 a memory organization for shared-memorymultiprocessors, which exploits the virtualMemory organization ofsoftware in TICC™-Ppde. This further reduces memory contention anddramatically increases data protection and security.

At this point, we introduce rules for condition migration overcommunication events: In the case of message sending using p:s() themessage characterizing conditions get switched between read/writememories. In the case of message forwarding using p:f() the conditionsdo not get switched:

□[{(p.rd:<C1?>?( ) & p.wr:<C2>?( ))(t₁)}[p^(S)(t₁)} →

q^(D)

(t₂)]          {(q.rd:<C2>?( ) & q.wr:<C1>?( ))(t₂)}]  (6.12)□[{(p.rd:<C1?>?( ) & p.wr:<C2>?( ))(t₁)}[p^(F)(t₁)} →

q^(D)

(t₂)]          {(q.rd:<C1>?( ) & q.wr:<C2>?( ))(t₂)}]  (6.13)The superscript, ^(F), in p^(F)(t₁) in (6.13) indicates that the messageis being forwarded.

Next two subsections present, PC-Solution (Produce/Consumer) andDP-Solution and ALLEOP-proofs associated with them. The solutions areimplemented without having to use semaphores [Dijkstra, 23,24], monitors[Hoare, 12] or sequential buffers. We have said this several times; butwe believe it is worth repeating, since semaphores and monitors are wellentrenched mechanisms in programming technology and are consideredindispensable. They have been in use for more than four decades now!

6.3. The Producer/Consumer Solution: PC-Solution

Our objective here is to illustrate use of parallel buffers. The networkfor the PC-solution is shown in FIG. 12 and the solution is presented inAppendix II. It has n producers, P[i], 0≦i<n, and m consumers, C[j],0≦j<m. connected to a distributor, D. The environment cell, E, is usedto start/stop the application based on an external interrupt signals.VirtualMemories P[j].f.vM=C.g[j].vM for 0≦j<m provide parallel bufferingfor products they send to D. VirtualMemories tuned to consumer portsC[j].g are used to send products to consumers. Please see Appendix IIfor the CIPs, TIPs, Polling cycles, and ALLEOPs of the implementation.We want to prove the following:

(Stmt 1) Every manufactured product is delivered to the distributor.

(Stmt 2) Every consumer with a request for product, gets the product.

CTL-assertions for the above two statements are:

(Stmt 1):

F[∀j∀x[x=P[j]:produceProduct()⋄(D.g_(j):msg().content=x)]  (6.14)

(Stmt 2): □[∀j(C[j].g^(s)⋄C[j].hasProduct)]  (6.15)

In (6.14), producer P[j] produces a product and the distributoreventually receives it at its port D.g_(j). In (6.15) the consumer C[j]sends in a request for product by executing C[j].g^(s) and eventuallygets the product.

The first task performed by the system is to transform (6.14) and (6.15)by eliminating the modal operators, □ and ⋄, using rule (5.32) inSection 5 and the ECT-Network in Table 7, 3129 and eventcharacterizations in Tables 7.1 through 7.3; universal instantiations of∀j to j and ∀x to product, eliminates the quantifiers, and finallyvirtual time points are postulated. The resultant CTL-statements areshown in (6.16) and (6.17). This task is simplified in this example,since there is only one unique causal chain for each j.

Transformed CTL-Statements: (Stmt 1a): □[∃(ctl.t₀ < ctl.t₁ < ctl.t₂)   [•→ product=P[j]:produceProduct( )(ctl.t₀)]    [•→ P[j].f.wr:msg().contents = product(ctl.t₁)]     →...→( D.g[j].rd:msg().content=product

(ctl.t₂)] (6.16) (Stmt 2a):  [∀(ctl.t₃)∃(ctl.t₃ < ctl.t₄ < ctl.t₅)       //consumer C[j] sends out a request      C[j].g^(S)(ctl.t₃) →(∃(k)(0≦k<n)D.g[k]:mR?( ))*(ctl.t₄)        →...→C[j].hasProduct(ctl.t₅)] (6.17)

The ECT-network for the PC-Solution is shown in Table 7 and theECT-blocks are shown in Tables 7.1 through 7.3. Reader should be able tofollow information provided by these tables through analogy withECT-tables presented in OG-Solution. The system picks information itneeds from these tables during proof construction. The generalrequirements GR-1 and GR-2 mentioned in Section 6.1 are satisfied forthe ECT-networks in Tables 7 and Tables 7.1-7.3. However, satisfactionof GR-3 does not follow immediately. We have to prove that the searchfor a delivered product performed by, (∃(k) (0≦k<n) D.g[k]:mR?())* in(7d,4) in Table 7.2 will succeed every time.

Evaluation of the statements (6.16) and (6.17) over the ECTs in Tables7.1 through 7.3 yields the following matching time points (references toevents corresponding to the virtual time points in the blocks are givenbelow:

For (6.16): ctl.t₀ = p[i]f.t₂: P[i] produces product, (7e,4) ctl.t₁ =p[i]f.t₃; puts it into writeMemory, (7e,5) ctl.t₂ = p[i]f.t₅; deliversit to D.g[i]: (7e,7)  (6.18) For (6.17): ctl.t₃ = (c[j]I.t₂|c[j]g.t₃);        requests product, ((7a,4)|(7b,8)) ctl.t₄ = dg[k]t.t₀; D beginssearch: (7d,4) ctl.t₅ = c[j]g.t₂; consumer gets it: (7b,5)  (6.19)

System identifies flow of events in the ECT-network in Tables 7.1-7.3that correspond to the flow of events in the CTL-statements and putsthem into trace formats. These are shown below: Trace (6.20) shows theflow of events from the time producer P[i] senses an order for a newproduct, to the time when the product is delivered to the distributorport D.g[i].

P[i].f:trace(p[i]f.t₀) =  {

P[i].f:mR?(

P[i].f^(D)

(p[j]f.t₀)

(p[i]f.t₁)}   [•→ product=P[i]:produceProduct( ) (p[i]f.t₂)]   [•→P[i].wr:msg( ).contents = product(p[i]f.t₃)]   [•→ P[i].f^(S)(p[i]f.t₄)]  ([→

D.g[i]^(D)

(p[i]f.t₅)]    || {

D.g[i].rd.msg( ).contents=product

(p[i]f.t₅)}     →...→ {(∃(k) (0≦k<n)D.g[k]:mR?( ))*(dg[k]t.t₀)})  →P[i].f:trace(p[i]f.t₅)] (6.20)Trace (6.20) specifies the following: On sensing receipt of a message atits port P[i].f, P[i] produces a product, puts it into the writeMemoryof P[j].f and sends it off to D.g[i], which uses it some time later fromits readMemory. This validates (6.16). Notice, the two time points,(dg[k] t.t₀, p[i]f.t₅), in (6.20) are incomparable. Thus, productdeliveries and search for products are not synchronized.

The trace (6.21) below displays the causal chain of events from the timeconsumer C[j] puts in a request for a product to the time C[j] has theproduct.

C[j].g:trace(c[j]g.t₀) = {

C[j].g:usedUp?( )*

(c[j]g.t₃)} [•→ C[j].g^(S)(c[j]g.t₃)]   ([

→ D.f[j]^(D)

(c[j]g.t₄]    ||[→...→{

D.f[j]:mR?(

D.f[j]^(D)

(c[j]g.t₄=df[j].t₀))

(df[j].t₁)}       {

(∃(k) (0≦k<n)D.g[k]:mR?( ))*(dg[k]t.t₀)

(dg[k].t₁)}       {

∃(product)D.g[k].rd.msg( ).contents =                     product

(dg[k]t.t₀)}        [•→ D.g[k]:moveProduct(D.f[j]) (dg[k]t.t₁)]       {

D.g[k].rd:msg( ).contents = φ &          D.f[j].wr:msg().contents=product

(dg[k]t.t₂)}        [•→ D.g[k]^(S)(dg[k]t.t₂)]//sends in an order for anew product        ([

→ P[k].f^(D)

(dg[k]t.t₃)]//order is delivered to the producer.             ||→...→P[k].f:trace(p[j]f.t₀ ≧ dg[k]t.t₃)        [•→ D.f[j]^(S)(df[j]t.t₃)]//sends product to consumer        ([

•→ C[j].g^(D)

(df[j]t.t₄)] //delivers product to consumer         //D proceeds to pollits next functionPort.        [•→ ∃(i)(0≦i<m)D.f[i]:trace(df[i].t₀=df[j]t.t₄)])]         //back to whathappens at consumer C[j]. In the following, consumer senses delivery.         {

C[j].g:mR?(

C.g[j]^(D)

(c[j]g.t₀ = df[j]t.t₄))

(c[j]g.t₁)}          {

C[j].g.rd:msg( ).contents = product

(c[j]g.t₁)}           [•→ C[j].g:pickUp( ) (c[j]g.t₁)]         {

C[j].g.rd:msg( ).contents=φ & C[j].hasProduct

(c[j]g.t₂)} (6.21)Flow of events in (6.21) is guaranteed only if the search, ∃(k)(0≦k<n)D.g[k]:mR?())*, succeeds every time. D.g[k] receives its deliveryfrom P[k].f. The search,

{(

∃(k)(0≦k<n)D.g[k]:mR?())*(dg[k]t.t ₀)

(dg[k]t.t ₁)}

in (6.21) begins at time dg[k]t.t₀ and ends at time dg[k]t.t₁ when theproduct is moved to D.f[j] (see (7d,6)). This search can succeed everytime if and only if there is a P[k].f for (0≦k<n) that delivered aproduct to D.g[k] before dg[k]t.t₁ and this product was not already usedup before dg[k]t.t₁.

The induction proof goes as follows: The search will succeed for thevery first customer because of orders put in by the distributor D duringits initialization (see (7c,5)). Suppose it succeeds in the N^(th)attempt. It will succeed in the (N+1)^(st) attempt, because after theproduct is used up in the N^(th) attempt, say at a port D.g[k], a neworder is put in to producer P[k] (see (7d,10). Since, search continuestill a product is found, it will certainly succeed when P[k] responds tothat order. It is also possible that the search found an as yet unusedproduct at some other port D.g[j]. System proves this interactively byvalidating assertions provided by the user. We will not present thedetails here. This satisfies requirement GR-3 in Section 6.1. Therefore,as per (6.21) every consumer receives the requested product.

However, to guarantee progress it is necessary to assume the following:

Axiom: □(∃(i,t)[→C[i].g^(s)(t)])  (6.22)

i.e., there is always a customer with a request for product, which isthe same as saying, there will always be new orders for products to beproduced. Otherwise, business stops and the distributor will just keepspinning around its empty ports executing its polling cycles. Also, ifthere is not enough demand for products then it is possible that someproducers just remain spinning. One may redefine the producer CIP tosuspend the producer if it keeps spinning for more than a specifiedamount of time. It will automatically resume operations, if demand picksup and an order is later delivered to it.

Comments: One of the problems we face in proof construction is, we haveto resort to proof by induction in situations, where a simple “StarOperation” in a regular expression of an FSP description could validatea requirement. This happens not only because we have no “states” butalso because of essential asynchrony in parallel operations. In mostcases, the induction proofs are quite trivial, and hopefully it would bepossible to devise strategies for a system to construct the proofsautomatically.

6.4. Dining Philosopher's Solution: DP-Solution

The DP-solution network is shown in FIG. 13. There is an environmentcell, not shown in the figure, which starts and stops the game. There isa butler, btlr, (marked B in FIG. 13) who distributes forks on requestand keeps the food supplied. There are five philosophers, P[0] throughP[4]. A philosopher can start eating only after he/she gets two forksfrom the btlr. There are only 5 forks on the table, btlr.frk[j] for0≦j<5. Every philosopher P[j] shares btlr.frk[j] with his/her leftneighbor P[j⊕₅4], and shares btlr.frk[j⊕₅1] with his/her right neighborP[j⊕₅1]. Thus, no two adjacent philosophers can eat at the same time.

Philosopher P[j] sends in a request for forks, by sending an emptymessage to the functionPort, btlr.f[j] via its port P[j].g. If bothforks, btlr.frk[j] and btlr.frk[j⊕₅1] are available, then btlr packs theforks into a container in the writeMemory of btlr.f[j] and sends themoff. Once this is done, forks will not be available for P[j⊕₅1] andP[j⊕₅4], until P[j] has finished eating and returns the forks. Ifphilosopher P[j⊕₅4] was eating or P[j⊕₅1] was eating at the time P[j]requested the forks, or P[j⊕₅1] was waiting for forks having put his/herleft fork btlr.frk[j⊕₅1] on reserve, then forks will not be availablefor P[j]. In this case, btlr puts P[j]'s left fork, btlr.frk[j], onreserve and philosopher P[j] waits until both forks become available.Once btlr.frk[j] is put on reserve, P[j⊕₅4] cannot start eating (again)before P[j] had eaten. Btlr.frk[j] is released from reserve only at thetime forks are sent to P[j].

Every philosopher P[j] always returns forks after he/she finishes eatingand goes into his/her thinking state T[j]. After thinking for a while,he/she gets hungry again and puts in an order for forks. Btlr keepsserving the philosophers in cyclic order, P[0]→P[1]→P[2]→P[3]→P[4]→P[0]→. . . →, until the game ends.

At any point in the game P[j] can be in one of three possible states:E[j] (eating), T[j] (thinking) or w[j] (waiting for forks). Game startswith all philosophers in state T[j], with all forks on the table andavailable to any philosopher, and food ready. Philosopher P[j] who hassent in a request for forks and whose request is sensed first by btlr,is served first by the btlr, and gets the forks first, even if all thephilosophers had sent requests for forks at the same time. After P[j]gets the forks, P[j⊕₅2] may get the forks next, if he/she had requestedthem. Then both may begin to eat and go to states E[j] and E[j⊕₅2],respectively. Others, for k≠j and k≠j⊕₅2 will wait for forks, if theyhad ordered them, and thus go to state W[k], or just keep thinking ifthey had not ordered any forks.

The CIPs, TIPs, ALLEOPs are given in Appendix III. The ECT-networks andECT-blocks are shown in Tables 8, 8.1, 9, 9.1 and 9.2. The gamesatisfies the following two axioms, which guarantee progress:

(Ax 1): ∀(j)[□(E[j] ⋄ (T[j] & btlr.frk[j].onTbl &         btlr.frk[j⊕₅1].onTbl &         

btlr.frk[j].rsrvd)] (6.23) (Ax 2): ∀(j)[□(T[j] ⋄ P[j]:hungry?( ))](6.24)(6.23) says, every eating philosopher always eventually returns theforks. (6.24) says, every thinking philosopher eventually gets hungry.

The states, E[j], T[j] and W[j] are defined as follows:

∀(t)∃(t₀≦t<t₁) (T[j](t)

  [•→ P[j]:thinking( ) (6.25)   (t₀)][

•→ P[j]:thinking( )

(t₁)]) ∀(t)∃(t₀≦t<t₁) (E[j](t)

  [•→ P[j]:eating( ) (t₀)][

•→ P[j]:eating( )

(t₁)]) (6.26) ∀(t) ∃(t₀<t₁<t₂<t₃)&(t₁≦t<t₃) (W[j](t)

    [P[j].g:mR( )*(t₀) & btlr.f[j].rsrvd(t₁) &      

btlr.f[j].rsrvd

(t₂) & (6.27)      (

P[j].g:mR( )*( )

(t₃)]Notice the starting and ending timings of actions in the abovestatements. W[j] is a composite state of p[j] and btlr.f[j].

The initial state for the game is,

[∃(t₀)∀(j) (

T(j) & btlr:frksAvlbl(j) &        btlr.fdContainer:full?( )

(t₀))]     (6.28)

∀(j)W(j) is the only deadlock state here, since for any j, P[j⊕₅4] canstart eating only after P[j] has finished eating for 0≦j<5, and P[j] isalso waiting for forks. Thus, none of the philosophers will be able tostart eating. In the following we give proofs for two claims: (i) If thegame starts at the initial state in (6.28) then the game will neverreach this deadlock state; and (ii) the solution is fair in the sense,every philosopher gets his/her turn to eat, every time he/she getshungry.

In order to simplify descriptions of possible states of the system letus follow the following conventions:

[j] = (E[j] | W[j]);

E[j] = (T[j] | W[j]);

[j] = (E[j] | T[j]); and ??[j] = (E[j] | T[j] | W[j]);   (6.29)One may think of states described below as being true at the end orbeginning of a polling cycle of btlr. We refer to such states asconfigurations. Thus, ∀(j)T(j) and ∀(j)W(j) are configurations. Userformulates the following CTL-statements in terms of the states, T[j],W[j] and E[j] using the notation in (6.29):

□[∀(j)W(j) ⋄ ∀(k)W(k)]//never gets out of the deadlock (6.30) state□[∀(j)T(j) ⋄ ∀[(∃(i)[(

E(i⊕₅4)&E(i)&

E(i⊕₅1) &         ((

E(i⊕₅2) & E(i⊕₅3)) |          (E[i⊕₅2)&

E(i⊕₅3)))] | ∀(k)T(k)] (6.31) □[∀(j)(W[j] ⋄ E[j])] (6.32)

Assertion (6.30) characterizes the deadlock configuration. In (6.31)eventually, either one or two philosophers are eating or allphilosophers are thinking. (6.32) asserts that every waiting philosophereventually eats. As we shall see, searches here do not involve findingmatching time points, but involve chasing the states of philosophers.

The ECT-networks and ECT-blocks in Tables 8, 8.1, 9, 9.1 and 9.2 areused in the proofs below. They are obtained from the traces derived fromthe ALLEOPs in Appendix III.

Here, each ECT-network has a block which defines the initial state ofthe network. This specifies truth values of predicates when the networkis started; i.e. symbolic evaluation begins. This will change asevaluations proceed from one port-TIP to another. If a predicate at achoice point in Table 9 is not specified in the initial state, or is notamong the predicates evaluated earlier in ECT-evaluations or cannot beinferred from definitions, then all causal chains emanating from thatchoice point are included as possible alternates in ECT-evaluations.Before the start of ECT-evaluation corresponding to any polled TIP thesystem updates the initial state, using results of evaluation made up tothat point, using definitions of distinguished predicates given inAppendix III, (III.35) and other definitions supplied by user in theappendix. The convention in ECT-evaluation is, predicates maintain theirtruth values until they are changed.

Butler ECTs have several choice points and parallel activations, asshown in Table 9, but does not have parallel activation forks. Since allphilosophers and the butler run in parallel, symbolic evaluation oftheir ECTs may be conducted in parallel, when needed. Let us begin withassertion (6.30), which is the simplest one to prove. Here the initialstate is

∀(j)[W(j) &

btlr:frksAvlbl?(j) & btlr.f[j]:mR?( ) &   btlr.f[j]:mR?( ) &btlr.f[j].rd:empty?( )] (6.33)instead of the one shown in Table 9. The predicates appearing in (6.33)have been declared as distinguished predicates; they are used to specifyinitial states, and to summarize configurations at the end of TIPevaluations. These initial conditions appear towards the end of the ECTBlock(9m) in lines (9m, 5-7). This is the only ECT block in which w[j]occurs. If there is more than one ECT block with w[j] then the systemshould verify given assertions starting from each such w[j]. Aftersetting the initial state to predicates in (6.33), evaluations of theECT-blocks in Table 9 leads again to w[j], following the evaluation pathcontaining blocks marked (9d)→(9f)→(9k)→(9m)→(9e). Block (9m) goes to(9e) directly without sending any message. As evaluation continues onegets the following sequence of ECT evaluations, as per polling cycle:

btlr.f[j]:ECT(...) → btlr.f[j⊕₅1]:ECT(...) → btlr.f[j⊕₅2]:ECT(...) →btlr.f[j⊕₅3]:ECT(...) → btlr.f[j⊕₅4]:ECT(...) → btlr.f[j]:ECT(...) →...→(6.34)Thus, one gets ∀(j) (W[j]→ . . . →W[j]), since nothing changes. Thus,the configuration never changes. System recognizes this after goingthrough evaluations corresponding to one complete polling cycle,starting at btlr.f[j] and ending at btlr.f[j⊕₅4]. Notice, in state w[j]the btlr does not send any response message back to P[j] in theECT-block (9m) and neither does any P[j] sends message to btlr. As perdefinitions of guards given in Tables 1 and 2, btlr.f[j]:mR?() evaluatesto true in every polling cycle since no response message is sent back.This proves (6.30).

Let us now consider the proof of (6.31). In the following we use Z torefer to a configuration at the end of a polling cycle. Applying rule(5.32), CTL-assertion (6.31) is converted to,

∀(Z)(∀(j)T(j)→ . . . →Z)

(Z⋄EZ)  (6.35)

where EZ, is the end configuration defined by,

EZ = [∀(k)T(k) | (∃(i)[(

E(i⊕₅4)&E(i)&

E(i⊕₅1) &         ((

E(i⊕₅2) & E(i⊕₅3)) |          (E[i⊕₅2)&

E(i⊕₅3)))] (6.36)

The first task is to find out what the configuration z could be afterone polling cycle of the butler, starting from the initial state, andupdating the initial state of btlr.f[j]:port-ECT() for each j before itsevaluation and following all alternate causal chains at each choicepoint in Table 9, where predicate values are not available. The systemquickly finds out that Z=EZ, as follows: In Table 8.1 Block(8b), for0≦j<5, philosopher P[j] gets hungry and sends request to the butler forforks by executing p[j].g^(s) at time p[j] g.t₀ in line (8b,5) anddelivers it to btlr.f[j] at the time point p[j] g.t₁=bf[j].t₀ for 0≦j<5.These message delivery times for different values of j are incomparable,since philosophers run in parallel. Polling times at which butler pollsbtlr.f[j] to sense message delivery are bf[j].t₁, for 0≦j<5, wherebf[j].t<bf[j⊕₅1].t₁ as per polling cycle definition in Appendix II. Theonly requirement here is that message deliveries should occur beforemessage sensing, in order for delivered messages to be sensed. If aphilosopher P[j] happens to have sent in a request before btlr polls itsport btlr.f[j], then btlr will sense the message receipt at that port,else it will not.

It is possible that all philosophers send requests simultaneously, noneof them send requests during a polling cycle of the butler, or some doand some do not. Since operations of the butler and philosophers are notsynchronized, while btlr polls its functionPorts it may sense a messagereceipt at some of its ports some times, or may not sense any message ina polling cycle, or sense messages at all of the ports in a pollingcycle. Thus, it makes sense to include all possible alternate causalchains that emanate from each choice point in Table 9. In the case ofthe predicate btlr.f[j]:msg():empty?() appearing in ECT-blocks (9f) and(9g) in Table 9, user supplies the following definition,

∀(j)[□(P[j]:hungry?( ) & btlr.f[j]:mR?( ))

        btlr.f[j].rd:msg( ):empty?( )] (6.37)

System verifies this definition using the ECT blocks in Tables 8 and 9and uses this definition to determine the branch to be taken at thechoice point with the condition btlr.f[j]:msg():empty?(). System usesdistinguished predicates given by users to update initial states, wherenecessary. Typically, the need for making logical inferences arises inECT-evaluations, only while evaluating predicates or while updatinginitial states.

Assertions (6.35) and (6.36) do not give any criteria for selectingcausal chains at choice points in Table 9. Thus, the system analyzes allpossible causal chains that are consistent with the predicates in theinitial state and given definitions, at each choice point in Table 9,and finds out that z in (6.35) is equal to EZ in (6.36). This issummarized by the tree in FIG. 14, where a possible configuration aftera polling cycle of butler is specified by the states in any one of thebranches in the tree. Reader may notice that every branch in FIG. 14satisfies the pattern in z: either all philosophers are thinking, or oneor two of them are eating. Thus, the configuration after the firstpoling cycle,⁵ starting from the initial state satisfies ⁵ The statementcapturing the fact that so far we have found (6.38) to hold trueimmediately after the first polling cycle starting from the initialstate, will be rather long. Such a statement would have to capture everypossible branch in FIG. 14.

□[∀(j)T(j)→ . . . →EZ].  (6.38)

Therefore, in order to prove (6.35) the system attempts to find aconfiguration Z1 such that

□[EZ→ . . . →Z1]  (6.39)

holds true by doing the following: It firsts creates an existentialinstantiation of the variable i in (6.36) by setting i=j, and proceedsas follows: The possible initial configurations are

[

E(j⊕₅4)E(j)

E(j⊕₅1)

E(j⊕₅2)

E(j⊕₅3)] or [

E(j⊕₅4)E(j)

E(j⊕₅1)E(j⊕₅2)

E(j⊕₅3)]. (6.40)Substituting for the negated states in (6.40) as per definitions givenin (6.29), results in (2⁴+2³) possible initial configurations. For eachinitial configuration the system finds the initial conditions thatshould be true for that configuration from the ECTs and definition ofdistinguished predicates given by user and includes them in the initialconditions block in Table 9 where appropriate. After doing this, foreach initial state it evaluates the ECT-blocks following all possiblecausal chains that are consistent with the given initial conditions, andfinds that Z1=EZ (for Z1 in (6.39) and EZ in (6.36)) holds true for allinitial conditions and

EZ=∀(j)W(j). This proves (6.35), (6.36) and (6.31).

Notice, by doing this the system effectively builds the state diagramfor the dining philosophers' solution starting from its implementation.Here we did not have to search for matching time points, but only forpossible configurations reached in polling cycles. Let us now state aLemma which follows from the state diagram computed by the system. Thislemma is useful to prove (6.32).

Lemma 1: □∀(j)[W[j]

(??[j⊕₅4]W[j]

T[j⊕₅1]         

 E[j⊕₅4]W[j]??[j⊕₅1]         

 T[j⊕₅4]W[j]T[j⊕₅1])] (6.41)This specifies what the states of philosophers P[j⊕₅4] and P[j⊕₅1] couldbe, if P[j] was in state W[j]. When states are substituted to expand thenotation in (6.41) we get 8 possible distinct triplets. The tripletsare:

T[j⊕₅4]W[j]E[j⊕₅1], T[j⊕₅4]W[j]W[j⊕₅1], W[j⊕₅4]W[j]E[j⊕₅1],W[j⊕₅4]W[j]W[j]⊕₅1], E[j⊕₅4]W[j]E[j⊕₅1], E[j⊕₅4]W[j]W[j⊕₅1],E[j⊕₅4]W[j]T[j⊕₅1], T[j⊕₅4]W[j]T[j⊕₅1] (6.42)The system easily verifies that the specified triplets are consistentfrom the state diagram it has already constructed. If the state diagramhas not been constructed, then the system can verify each triplet bysetting up appropriate initial states for W[j] and evaluating theECT-blocks in Tables 8 and 9, for an arbitrarily chosen j. For eachtriplet in (6.42) the states not specified in (6.42) can be any statethat is consistent with the specified triplet.

The proof of (6.32) follows from the fact that every eating philosopherreturns the forks (from (6.24)), every thinking philosopher eventuallygets hungry (from (6.25)), and when P[j] is waiting P[j⊕₅4] cannot starteating because btlr.frk[j] has been reserved by P[j]. If P[j⊕₅4] wasalready eating while P[j] was waiting, then after P[j⊕₅4] finisheseating, in the first polling cycle that immediately follows the cycle inwhich P[j⊕₅1] returns the forks, P[j] will get his/her chance to eat. IfP[j] had to wait over several polling cycles of butler because P[j⊕₅4]was eating for a long time, then by Ax 1 (6.24) it is possible thatP[j⊕₅1] may begin to eat again after returning the forks, This mayhappen several times before P[j] gets his/her forks. But, eventually,P[j] will get his/her forks, since P[j⊕₅4] cannot start eating againuntil P[j] has finished eating. This is illustrated in FIG. 15. Here,the argumentation is similar to FSP argumentation using regularexpressions.

Let us consider the cases for T[j⊕₅4]W[j]T[j⊕₅1] and w[j⊕₅4]w[j]W[j⊕₅1]in (6.42). Assume, polling starts at btlr.f[j]. In the case ofT[j⊕₅4]W[j]T[j⊕₅1] the only possibility is that it changes to

E [j⊕₅4]E[j]

E[j⊕₅1]. Here P[j] has begun to eat, and so the proof ends. In the caseof w[j⊕₅4]w[j]w[j⊕₅1] the following holds: it follows from (6.35) and(6.36) that there should always be at least one eating philosopher. Userprovides the assertion,

□∀(j)[W[j⊕₅4]W[j]W[j⊕₅1]

 (W[j]W[j⊕₅1]E[j⊕₅2]

        W[j]W[j⊕₅1]

E[j⊕₅2]E[j⊕₅3])] (6.43)This assertion is easily validated through evaluations, using (6.36),(6.39) and the configurations in FIG. 14. In the case ofw[j]w[j⊕₅1]E[j⊕₅2], by Ax 2 (6.25), it has to lead to the followingsequence of transitions:W[j]W[j⊕₅1]E[j⊕₅2]→W[j]W[j⊕₅1]T[j⊕₅2]→W[j]E[j⊕₅1]T[j⊕₅2]→E[j]T[j⊕₅1]??[j⊕₅2].Therefore, P[j] eventually eats. The transitions above are all verifiedby the system. Similar transitions occur also for the case, w[j⊕₅1]

E[j⊕₅2]E[j⊕₅3].

For each case, the system evaluates the ECTs going through successivepolling cycles, starting with the appropriate initial states, until thestate E[j] is obtained in a polling cycle as the inevitable (onlypossible) state for P[j]. In each polling cycle the initial states areupdated before btlr.f[j]:port-ECT() evaluation for each j. This issimilar to state search in an FSP. In this particular problem, thesystem may stop repeating its polling cycles when configurations thatwere reached earlier occur again. This is possible here because thesolution has a finite-ALLEOP. This search succeeds in every case. Butthere are difficulties in this kind of search.

If E[j] is not reachable then for non-finite ALLEOPs it is possible thatthe system may never terminate, unless user specifies appropriatetermination conditions, or system encounters a contradiction, or userstops the system and examines the traces.

Remarks: ALLEOP-proofs are constructed by deriving ALLEOPs andECT-networks from implementations and by evaluating given CTL-assertionsover the ECT-networks and analyzing the resultant causal chains. Thesystem presents the causal chains it finds in the ECT-network in theform of traces. Proof construction is interactive. In all cases, userprovides CTL-assertions to be validated and assertions that may guidecausal chain (trace) analysis. System validates each assertion providedby user and uses already validated assertions to find new traces, whenappropriate. We have illustrated this proof process above for a fewsimple examples. To simplify the presentation, we did not present thetraces discovered by the system during its searches.

There are five kinds of inter-related activities in ECT-evaluations: (i)Setting up starting and ending configurations that are consistent withgiven CTL-assertions, (ii) finding matching time points betweenCTL-assertions and ECTs, when needed, (iii) finding truth values ofconditions at choice points in an ECT-network, (iv) finding all tracesthat lead to ending configurations from starting configurations, and (v)analyzing the traces to validate claims in CTL-assertions. In the caseof finite-ALLEOPs, user intervention may be needed only for the item (v)above. In the case of non-finite-ALLEOPs it may be needed for both (iv)and (v).

The proof theory for these proofs is not a complete proof theory, in thesense that the system cannot by itself conclusively proof all provableCTL-assertions. This is because of dependence on user interactions initems (iv) and (v) above. As we gain more experience, it should bepossible to automate proof construction to progressively greaterextents, by identifying ALLEOP-patterns that are typical, or byestablishing correspondences between FSP structures and finite-ALLEOPstructures, where possible. We could not state the proof theoryindependent of how TICC™-Ppde is organized, how it operates, and thecomputational significance of what is being proven. Before defining theproof theory, we define the denotational fixed point semantics forTICC™-Ppde programming system. This defines the computationalsignificance of what is being proven.

The next subsection introduces criteria that should guide a user togenerate CTL-assertions to be validated for a given application, Ap.

6.5. Correctness of Implementations

Let Ap:Pthreads(), Ap:ALLEOPs(), Ap:ECTs() and Ap:CausalNet(),respectively, denote the pthreads, ALLEOPs, ECTs, and causalnet ofapplication Ap in an implementation of Ap. The causalnet isautomatically generated by the SMS, as described in Section 7. Thepthreads in Ap: Pthreads() are defined by user. They are pair wisemutually independent, except when the same pthread is executed inparallel by cells belonging to a cell-group. Also, each pthread is ashort sequential program containing only the basic programmingstatements. These make it possible to prove independently provecorrectness of each pthread. Designers and implementers have theresponsibility to provide pthread characterizations. The ALLEOPs andECTs are generated automatically by the system from implementationspecifications.

Let us write, (Ap:CausalNet() satisfies Ap:ALLEOPs()), if the causalnetgenerated for Ap during its run does not violate the event patterns andpartial ordering in Ap:ALLEOPs(), and all events in Ap:CausalNet() occurwithin specified time limits. SMS described in Section 7 performs thismonitoring constantly to check whether (Ap:CausalNet() satisfiesAp:ALLEOPs()) holds true, while Ap is running.

Correctness of transactions and the concept of two ports connected by apathway being well-matched were defined in Section 1.2.2. Let us define,Ap:Correct() is valid, iff and only if all pairs of ports in Ap that areconnected by pathways in application Ap are well-matched. LetAp:Requirements() be the design requirements for application Ap thatwere developed before design began and updated since then. Definitionsof correctness of transactions in Ap, definitions of Ap: Requirements(),and specifications of time limits for transaction completions may all bedeveloped by designers and implementers, interactively with TICC™-Ppde.It is, of course, possible that (Ap:CausalNet() satisfies Ap:ALLEOPs())holds for an implementation in a given run, but the implementation isnot correct. To avoid this possibility, we would like the followingvalidation criterion to hold true for an implementation:

[(Ap:CausalNet( ) satisfies Ap:ALLEOPs( )) &  (Ap:ECTs( ) satisfiesAp:Requirements( ))]

 Ap:Correct( ) (6.44)Clearly, truth of (6.44) depends on the set of CTL-assertions that werevalidated for Ap. Thus, (6.44) and the concept of correctness definedabove specify a validation criterion in the sense that it may be used tochoose the set of CTL-assertions that should be validated for a givenimplementation. The CTL-assertions we validated for the simple exampleswe presented do satisfy (6.44) for those implementations. Identifyingthe set of CTL-assertions whose validity establishes the correctness ofan implementation Ap is guided by (6.44) and definition of Ap: Correct(). We have assumed here that designers will do this. Clearly, ifvalidation of an implementation of a system is such that it satisfies(6.44), then it makes good sense to use SMS to verify correctness ofperformance of that system through dynamic monitoring. In this case, itmay be possible to use validated assertions as guides to specifystrategies to diagnose errors that may occur at run time, and may bealso use the validated assertions to specify strategies for selfcorrection. These are significant topics for future research. The uniquefeature of TICC-Ppde is that, it automatically provides the SMS that isneeded to dynamically monitor system performance throughout its lifetime, and provides methods to validate system implementations throughCTL-assertions. Since all validations and correctness checks ultimatelydepend on ALLEOPs, we refer to the proofs presented here asALLEOP-proofs.

During the validation process, while finding matching time points, thesystem may identify Events that are incomparable as per ALLEOPs, butshould be either synchronized (occur at the same time) or coordinated(one of the Events should always occur before another) as perCTL-assertions. A pair of Events should be candidates for suchsynchronization or coordination, only if synchronization andcoordination do not negate any of the validated CTL-assertions in whichthe Events appear. We introduce in the next subsection ad hocsynchronization and coordination methods that may be used in TICC™-Ppdeto introduce needed synchronization and coordination into an alreadycompleted implementation, when necessary, with no need for reprogrammingthe pthreads.

The principal task of system implementation in TICC™-Ppde is notprogramming. Programming pthreads and conditions are relatively trivialmechanical tasks. The principal tasks that are difficult are, (i)setting up the TICC™-network, (ii) defining TIPs (iii) characterizingthe needed pthreads and (iv) identifying the CTL-assertions that shouldbe validated. The structure of TICC™-networks provides a medium in whichalternate organizations may be tested and explored. The TICC™-paradigmshifts the nature of the art of system design and implementation fromthe art of programming to the art of identifying needed subsystems,specifying interactions among the subsystems and proving correctness.

6.6. Limit Testing, and Ad Hoc Coordination and Synchronization

Limit Testing Branching trees of ECTs and partial orderings of timepoints may be used to validate varieties of useful system properties.One useful property to prove in real time systems is that the requiredpartial orderings of time points is always preserved in spite ofvariations in TIP execution times. This is done through limit testing.

For the TIP at a port C.p, define time bounds, (τ^(P) _(min),τ^(P)_(max)): τ^(P) _(min) is the minimum time interval needed to completeexecution of the TIP at p starting from the time message was deliveredto p, and τ^(P) _(max) is the maximum time interval that might beneeded: τ^(P) _(max)<(τ^(P) _(min)+2Δ^(C) _(max)) where Δ^(C) _(max) isthe maximum time needed for the parent-cell, C, of the port C.p tocomplete one polling cycle and service all ports with pending messagesand get back to servicing port C.p, in case message at C.p was missed inthe first polling cycle. 2Δ^(C) _(max) is used here because C.p could bethe last port serviced in the next polling cycle.

Suppose there were two traces, one leading to port C.p and anotherleading to port D.q, and cells C and D were not connected by any causalchain. Let it be required that occurrence of a pair of events,X^(P)(t^(P)) and X^(q)(t^(q)) at ports C.p and D.q, respectively, shouldalways be such that (t^(P)<t^(q)). Let (p[0], . . . , p[r−1]=C.p) be theports in the causal chain that leads to X^(P) and (q[0], . . . ,q[m−1]=D.q) be the ports in the causal chain that leads to X^(q). Lett_(n)(p[0]) and t_(n)(q[0]) be the times at which the n^(th) messageswere, respectively, delivered to ports p[0] and q[0]; τ^(P[j]) _(max) isthe maximum time needed to complete the execution of p[j]:tip();τ^(q[i]) _(min) is the minimum time needed to complete execution ofq[j]:tip(); and t^(P) and t^(q) are the times at which events X^(P) andX^(q) occur. Then following should hold true for the pair of portsequences:

t ^(P)≦(t _(n)(p[0])+Σ{τ^(P[j]) _(max)|0≦j<r})<(t _(n)(q[0])+Σ{τ^(q[i])_(min)|0≦i<m})≦t ^(q)  (6.45)

Here, we require that events X^(P) and X^(q) should be cyclesynchronized.

Ad hoc Coordination: Let us now assume that condition (6.45) was notsatisfied. How may it be enforced without having to do extensivereprogramming? To be specific, let us postulate two cells C₁ and C₂ thathave ports C₁.f₁ and C₂.f₁ that are not connected to each other by acausal chain in the ALLEOPs of an implementation. Suppose, correctoperation of the system required that the TIP at C₂.f₁ should beexecuted only after the TIP at C₁.f₁ had been executed. Let us writethis requirement as

□[([

•→ C₁.f₁:tip( )

(t₁)/*evaluation completed*/] &   [•→ C₂.f₁:tip( ) (t₂)/*evaluationbegins*/])

 (t₁ < t₂)].This problem is easily solved in TICC™-Ppde by using spawning andport-vectors, as illustrated in FIG. 16.

Install two other ports, C₁.g and C₂.f₂, define [C₂.f₁, C₂.f₂] as aport-vector and install a branch connecting C₁.g to C₂.f₂, as shown inFIG. 16. Now, C₂ may service a message at C₂.f₁ only after C₂.f₂ hasreceived a signal from C₁.g. C₁.g sends this signal after executingC₁.f₁:tip(). The TIPs at C₁.f₁ and C₂.f₁ will have the forms,

(C₁.f₁:mR?( ) & C₁.g:pR?( )*){C_(1.)f₁:r( ).s( ); C_(1.)g:s( )}(C₂.f₁:mR?( ) & C₂:f₂:mR?( )*){C_(2.)f₁:r( ).s( ); C_(2.)f₂:s( )} (6.46)With this, C₁:f₁ and C₂:f₁ will be cycle synchronized and therequirement will be always satisfied. Indeed, this arrangement may beused to coordinate not just pairs of ports, but to cycle synchronizegroup-to-group interactions as well, as in

□([

•→ C₁.f:tip( )

(c₁.t),

•→ C₂.f:tip( )

(c₂.t),...,    

•→ C_(n).f:tip( )

(c_(n).t)/*evals done*/]  & [•→ D₁.f:tip( ) (d₁.t)], [•→ D₂.f:tip( )(d₂.t)],...,    [•→ D_(m).f:tip( ) (d_(m).t)]/*evals begin*/]  

 [∀(t₁ ε {c₁.t, c₂.t,..., c_(n).t})∀(t₂ ε {d₁.t, d₂.t,..., d_(n).t})     (t₁ < t₂)]. (6.47)using group-to-group signal exchange described in Section 7. Here theonly modifications needed in the implementation in order to incorporatethe needed cycle synchronization are (i) setting up the neededgroup-to-group pathway, and (ii) changing the TIP definitions. The restof the implementation remains unchanged. Arrangement here is verysimilar to the way time signals are used in asynchronous hardwaresystems to coordinate subsystem activities.

Ad hoc Synchronization: In TICC™-Ppde, polling cycles of different cellsare not synchronized to each other. Yet, at times it may be necessary tosynchronize servicing of ports not connected to each other by pathwaychains and not in a cell-group. We will call them isolated cells. Thus,one may wish to enforce the synchronization,

[→(C₀.f:tip(), . . . , C_(n−).f:tip())(t)]  (6.48)

for the isolated cells C_(j) for 0≦j<n. This is done by installing theself-loop pathway shown in FIG. 17. Ports C_(j).g for 0≦j<n are attachedto cells C_(j) and each port C_(j).g is connected to the self-looppathway as shown in FIG. 17. The TIP at each C_(j).f has the form,

C_(j).f:mR?(){C_(j).g:s(); C_(j):g:mR?()*{C_(j).f:r().s()}}.  (6.49)

Here, each cell C_(j).g transmits a signal to itself through theself-loop pathway as soon as it receives a message via C_(j).f. Asynchronized signal is delivered to all C_(j).g for 0≦j<m, by agent a0,only after all cells C_(j) have sent signals via their respective portsC_(j).g (the protocol for this is described in Section 7). Each C_(j)responds to the received message at its port C_(j).f immediately afterreceiving this synchronized signal. It is possible that one of the cellsconnected to agent a0 in FIG. 17 is a global clock. In this case, allthe cells would respond to their respective messages at ports C_(j).fsynchronized to the global time, or any other event in the system. Thisis almost like using clocked rendezvous technique, but much moreflexible: synchronization machinery does not have to be programmed intothe pthreads, only the self-loop network has to be installed and theTIPs have to be modified.

Synchronization and coordination are done here as an after thought.These kinds of ad hoc synchronization and coordination cannot be done inπ-calculus, in Actor systems, in CSP or any other currently availableparallel programming paradigm, without having to do extensivereprogramming. We will conclude this section with some comments on NFSPALLEOPs that may contain an arbitrary number of nodes.

6.7. An Example of a Dynamically Growing Non-Finite State ALLEOP

A simple network for this is shown in FIG. 18. It has n cells. Eachcell, C[i], is connected to a csm (Communications System Manager). Whena cell is installed, a private pathway to its associated csm isautomatically set up from a designated csmPort (subclass of generalPort)of the cell. Any cell that needs to dynamically install new cells orpathways will send service request messages to its associated csm, byinvoking the appropriate (cell:installCell( . . . );cell:installPathway( . . . );) methods. These methods are provided bythe TICC™-Ppde system. A cell x may also send a request to its csm todestroy x or destroy a pathway. Cells use csm to install other cells andpathways because these are expensive operations, taking 100 to 250microseconds. After sending a request to csm via its csmPort a cell mayproceed to service its other ports and get back to csmPort in an ensuingpolling cycle to receive the response from csm and take appropriatealready programmed actions. The csm services a request only if therequesting cell has the appropriate privileges. In any case, the csmsends back to the requesting cell a response message.

When application starts, the network in FIG. 18 contains only the cellsC[0], x and csm. X activates C[0] by sending a message to itsfunctionPort, C[0].f. Initially, the csmPort of C[0] is tuned to agenta1 as shown in FIG. 18. When activated, as part of its initialization,C[0] requests its csm to install C[1], and connect its port C[0].g toC[1].f via a pathway. When C[0] gets a response from the csm that thetask has been completed, it disconnects C[0].csmPort from agent a1,sends a message to C[1].f, via C[0].g, and then suspends itself, therebyreleasing its assigned CPU. The message sent to C[1].f will contain acondition, which is used by C[1] as described below.

The message sent to C[1].f activates C[1] to run in one of the availableCPUs. When activated, C[1] in turn does the same thing, tuning itscsmPort to agent a1, installing and activating the next cell C[2], thendisconnecting C[1].csmPort from a1, and then suspending itself, unlessthe condition in the received message stops it from doing so. Thus, eachnewly installed cell continues to install and activate yet another celland suspends itself, unless the received condition prevents it. Thiscauses the network to grow until the condition stops it.

When the condition stops the growth, say at cell C[n] for some n>1,instead of installing a new cell, C[n] responds to the message itreceived at its port C[n].f by sending a reply to C[n−1].g and thendestroys itself, thus releasing its assigned CPU. At the time theresponse message from C[n].f is sensed by C[n−1].g, C[n−1] resumes itssuspended operation in one of the available CPUs, repeating what C[n]just did. Thus each newly installed cell completes its transaction anddestroys itself one by one until C[0], x and the csm are the only cellsremaining in the network. At that point C[0] responds via its portC[0].f to the service request it initially received from X.g and thuscompletes the transaction.

It is not important to show the details of definitions in this example,namely, facilities for dynamic creation and destruction of cells andpathways, TIPs, ALLEOPs and traces. It is sufficient to note that thefollowing causal sequence would occur in the trace. It starts with themessage sent by X.g to C[0].f, continues up to C[n].f and then beginsthe reverse process. The causal chain is shown below:

/*communication events during progressive creation and activation of newcells.*/ X.g^(S)[ ]→ C[0].f^(D)[ ]→...→C[0].g^(S)[ ]→ C[1].f^(D)[]→...→C[1].g^(S)[ ]→ C[2].f^(D)  →...→C[2].g^(S)[ ]→ C[3].f^(D)[ ]→...→→...→ C[n−1].g^(S)[ ]→  C[n].f^(D)[ ] →...→Communication events during progressive completion of transactions withnew cells destroying themselves

 C[n].f^(S)[ ]→ C[n−1].g^(D)[ ] →...→ C[n−1].f^(S)[ ]→  C[n−2].g^(D)[ ]→...→ →...→   C[2].f^(S)[ ]→ C[1].g^(D)[ ]→...→ (6.50)   C[0].f^(S)[ ]→X.g^(D)[ ], n ≧ 0 Setting ‘X.g’=‘g’, ‘C[i].f’=‘f_(i)’ and (6.50)‘C[i].g’=‘g_(i)’,for 0≦i≦n, reduces to, for n > 0,  g^(S)f₀ ^(D)[(g₀^(S)f₁ ^(D)) (g₁ ^(S)f₂ ^(D))...(g_(n−1) ^(S)f_(n) ^(D))][(f_(n)^(S)g_(n−1) ^(D)) (6.51)  (f_(n−1) ^(S)g_(n−2) ^(D))...(f₁ ^(S)g₀^(D))]f₀ ^(S)g^(D) Now setting g^(S)f₀ ^(D) = α, g_(i) ^(S)f_(i+1) ^(D)= β_(i), f_(i+1) ^(S)g_(i) ^(D) = β_(i) ⁻¹ for 0≦i≦n and f₀ ^(S)g^(D) =α⁻¹ we get the context dependent sequence,   α[β₀β₁ ... β_(n)][β_(n) ⁻¹... β₁ ⁻¹β₀ ⁻¹]α⁻¹, n ≧ 0, (6.52)Thus, ALLEOP for this would clearly not be a finite-ALLEOP, yet it wouldhave a finite description. In general, the ALLEOP associated with adynamic network can be general recursive.

We now proceed to present the group-to-group message transfer protocolthat includes (i) SMS facilities for generating a dynamically growingcausalnet for an application while running in parallel with theapplication, (ii) facilities for data dependent security checks, where amessage is delivered only to ports that satisfy a priori specifiedsecurity requirements, and (iii) facilities for automaticsynchronization and coordination.

7. Protocol for Group-to-Group Communication and the Self MonitoringSystem

Using ALLEOP models to prove CTL-assertion through ECT-evaluations, andthe built-in facility for the Self Monitoring System (SMS) are integralparts of TICC™-Ppde. They are unique to TICC™-Ppde. Without discussinghow the infrastructure for SMS is integrated with message exchangeprotocols, this presentation will be incomplete. We do this in thissection, taking a variant of the group-to-group Das-pathway as anexample.

For dm-pathways, group-to-group message exchange delivers servicerequest from parent-cells of generalPorts in a port-group in onemultiprocessor of a computing grid, to different port-groups offunctionPorts in different other multiprocessors in the grid. Responsemessages are sent in sequence by the functionPort groups, in amultiplexed mode. Response messages are gathered together by thegeneralPort group that sent the service request, with the provision, ifreceived messages were not consistent with each other then are-computation may be requested. Each multiprocessor in a griddynamically constructs the SMS causalnet that pertains only to the cellsoperating in that multiprocessor. Dm-pathways use 4-state hardwareagents, 4-state software ports, and use hardware routers and switches aswell. Thus, the protocol is more complex than the one described here. Wehave provided for three types of completion signals for three modes ofmessage transmission in sm-pathways: s for send mode, f for forwardmode, and h for halt mode for halting computations. The halt mode isused only by generalPorts. In the halt mode no service request messageis sent and the pathway may be dismantled. Cells in a cell-groupcoordinate types of signals they send by exchanging information throughthe scratchpad of the virtualMemory M in FIG. 19.

In shared memory environments, as mentioned earlier, the read/writememories of the virtualMemory of the pathway are switched in the sendmode and not switched in the forward mode. The choice between sendingand forwarding is determined by the TIP. In distributed memory messageexchanges, there is no forward mode or halt mode, instead there are endof data signal, e, and abort signal, a, to dismantle a pathway and causethe network routers and switches to go to their active states, waitingfor new signals to start a new pathway establishment process.

The modified Das-pathway for group-to-group message passing is shown inFIG. 19. Message is exchanged between a group of generalPorts, G=[g₀,g₁, . . . , g_(n−)], and a group of functionPorts, F=[f₀, f₁, . . . ,f_(m−)]. The pathway has four agents: M, a1, a2 and a3. They areconnected to each other by h-branches as shown in the figure. All thefour agents are attached to the virtualMemory, M. To make the diagramclear, a2 and a3 are shown in FIG. 19, in an offset attached to M. Theagent M is tuned to port-group G, a1 is tuned to port-group F, a2 istuned to the functionPort eb.f₁ and a3 is tuned to the functionPorteb.f₂ of the eb cell, which is the EventBuilder cell. Agenta0.nxt=[a1,a2] and a1.nxt=[a0,a3]. The functionPort vector, [eb.f₁,eb.f₂] is attached to the eb cell. We will soon see the task performedby this cell. Each eb cell may service several distinct pathways,connected to each pathway through a separate pair of ports in afunctionPort vector and associated agents, like the ports [eb.f₁, eb.f₂]and agents, a2 and a3 in FIG. 19. An application may have several sucheb cells.

Each port in port-groups G and F has associated with it the protocolthat is needed to transport a message from one end of the pathway shownin FIG. 19 to its other end. When a parent-cell of a port in aport-group completes its computation and is ready to transmit a message,the cell begins executing the protocol associated with that port. Thus,all the parent-cells of ports in a port-group will begin to evaluate theprotocols at their, respective, ports in parallel at time points, whichare mutually incomparable. Agents on the pathway coordinate messagetransmission.

Agents, ai for i=0,1 in FIG. 19 have each three attributes defined forit: one is ai.selectedPort, which could be any port tuned to ai, thesecond one is a Boolean attribute, ai.dC (‘dC’ for ‘deliveryComplete’),which is initialized to false, the third is a vector called completionsignals Vector, ai.csV. It has one vector element for each port that istuned to ai, to store signal received from that port, and one elementfor signal received from ai.nxt[1]. Each element assumes one of fourpossible values>0: ai.csV[j]=(c|f|h|ignore)>0, c (‘c’ for completionsignal), used to send a message, f for forwarding a message, and h forhalt, for 0≦j<ai.csV:size ()−1; these signals are sent by ports that aretuned to ai. The last element, ai.csV[ai.csV:size()-1] stores the signalc sent by agent, ai.nxt[1]. There is a fourth signal may be used by aito set ai, for 0≦j<ai.csV:size()−1, based on conditions computed duringmessage transmission, to indicate that the port corresponding to jshould be ignored. We will soon see how elements of ai.csV are used.

GeneralPorts in G send a joint service request to functionPorts in F.The generalPort group is G=[C_(i).g_(i)|0≦i<n−1], where n−1=G:size() anda0.csV:size()=n. Protocol at each C_(i).g_(i) in the generalPort group,G, in FIG. 19, has the form shown below (we use ‘.’ to specifyconcatenation of successive sequential components of a program).C_(i).g_(i):protocol() has two concatenated components,C_(i).g_(i):prefix() and c_(i).g_(i):suffix(). Statement (7.2a) belowdescribes what C_(i).g_(i):prefix() does. We will later see whatC_(i).g_(i):suffix() does. In the following m−1=F:size() anda1.csv:size()=m.

C_(i).g_(i):protocol( ) = C_(i).g_(i):prefix( ) . C_(i).g_(i):suffix( );(7.1) C_(i).g_(i):prefix( )=  [(a0.selectedPort≠C₀.g₀)?(){a0.selectedPort=C₀.g₀} .   (a0.csV[0]≠0)?( ){ a0.csV[0...n−2]=0;  a1.csV[0...m−2]=0;} .    a1.dC?( ){a1.dC = false;) . (C_(i):x_(i) →g_(i):x_(i) → a0) .     (a0:selectedPort ≠ C_(i).g_(i))?( ) {a1:dC?( )*{};}] (7.2a) C_(i).g_(i):suffix( ) =  [AP1(a0.csV[0...n])?()*{C_(i).g_(i):suffix-body( );}] (7.2b)

When a parent-cell C_(i) is ready to send a message it immediatelyexecutes C_(i).g_(i):prefix(), in parallel with the parent-cells ofother ports in group G. This parallel execution is not synchronized;different parent-cells C_(i) may do this at different times. Whileexecuting C_(i).g_(i):prefix(), C_(i) first sets a0.selectedPort=C₀.g₀if it has not been already set, then initializes the vectors, a0.csV anda1.csV, if they have not been already initialized; the last elements ofthese vectors are not initialized. C_(i) then sets a1.dC=false if it isnot already false. It is possible that two or more cells C_(i) performthe same initialization simultaneously. There will be no mutualinterference; no pthread-lock is needed here.

After initialization, each cell sends one of three possible completionsignals, x_(i)=c|f|h>0, to its port C_(i).g_(i) and the port forwardsthis signal to a0. After this, C_(i) evaluates the expression,(a0.selectedPort≠C_(i).g_(i))?(){a1:dC?()*{ };}. This causes all cellsC_(i) other than the parent-cell of a0.selectedPort to wait until a1:dCbecomes true; thus they stop executing the protocol any further. Whena1.dC becomes true each cell C_(i) may begin to process its next port inits polling-cycle servicing order. Meanwhile, before a1.dC becomes true,while all the other cells are waiting for a1:dC?() to become true, theparent-cell C₀ of a0.selectedPort begins to execute C₀.g₀:suffix(); thiswill be the only cell executing C₀.g₀:suffix().

The agent a0 will expect to receive signals, x_(j)>0, from eachC_(j).g_(j)εG for which a0.csv[j]≠ignore, and one signal, c=x_(n−)>0,for a0.csV[n−1], from a0.nxt[1]=a2. When a0 receives signal x_(j)>0 fromport C_(j).g_(j), it will know that cell C_(j) has completed itscomputation. When it receives signal, c>0, from a2, it will know,whatever cell eb did during the previous message exchange through thesame pathway, has been completed. These signals become the arguments ofthe agreement protocol function, AP1, used in the guard, a0:AP1(a0.csV[0 . . . n−1])?()* in (7.2b). C₀ executes this guard, since it isthe only cell still continuing to execute the protocol. The guardevaluates to true only when all its elements are >0; i.e., after it hasreceived all the expected signals. It is executed repeatedly until itbecomes true. When it becomes true, the parent-cell C₀ ofa0.selectedPort executes C₀.g₀:suffix-body(). The suffix-body is thesame for all generalPorts, C_(j).g_(j) in G. So it does not matter whichgeneralPort is chosen as the selectedPort. We will soon see what thissuffix-body does. Before defining g_(i):suffix-body(), we have to definesome more variables and methods. They are all associated with agents andports in the sm-pathway; we do this now.

Security Specification In the following, a1.M refers to thevirtualMemory attached to a1. For 0≦j<m−1=F:size(), agent a1 sendsdelivery signal to a port, D_(j).f_(j) that is tuned to it, only if theport D_(j).f_(j) satisfies a specified security condition,a1:Sy(D_(j).f_(j), a1.M)?(). If for any j, a1:Sy(D_(j).f_(j), a1.M)?()is false then a1.csV[j]=ignore is set, i.e., the j^(th) port is thenignored. It is possible that users define different security functionsfor different pathways. After is delivery signal has been sent to allsecure ports the variable, a1.dC is set to true.⁶ ⁶ The system has twodefault security definitions: In one, every port in F receives message.In this case, there is no security check. In the other, a securitylevel, M.security, a security mode, M.rd:msg() mode, and for each fεF asecurity level, f.security, are defined. A message in M is delivered toport f if and only if M.security≦(f.security+M.rd:msg().mode). Messagesmay thus be delivered to less secure ports by setting the M.rd:msg()mode high. Cells have privileges. A cell may request other cells orpathways to be dynamically installed only if it had the requisiteprivileges. A cell may temporarily delegate its privileges to anothercell. A cell may also temporarily delegate the security status at one ofits ports to a port of another cell, if both cells had appropriateprivileges to do so, the delegated security status being associated witha condition that specifies when the delegated security should beautomatically revoked. The condition could be based on the number ofmessages exchanged using the delegated security status. This securitysystem is built into the prototype TICC and TICC-Ppde.

Other Pathway Variables and methods: The variable a0.ccS holds the valueof the composite completion Signal (ccS) computed by the secondagreement protocol method, AP2, used in (7.4-(i)) below. AP2 is definedin (7.3). The method, a0:resetPathway() is used in (7.4) to reset thesm-pathway in which a0 appears, to its initial state. The methodexception (f) issues an exception at port fεF to warn observers aboutsecurity failure at port f. The method a0:swMem() switches theread/write memories of a0. The method, p:timeStamp() sets the time stampat a port p, in the local time of the parent-cell of p, indicating whenthe delivery signal was delivered to p. The condition p:active?() checkswhether the parent-cell of p is already running in a CPU; the method,p:activate() activates the parent-cell of p in an available CPU. Asmentioned earlier, TICC-Ppde itself manages all CPU assignments and cellactivations.

We are now ready to define g_(i):suffix-body(): It uses the secondAgreement Protocol function, a0:AP2[a0:csV[0 . . . n−2]]. Notice, thisdoes not include in it the signal, a0:csV[n−1] received from agent a2.It only examines the completion signals that a0 has received from thegeneralPorts in G, and sets the composite completion Signal, a0.ccS=a0:

a0:AP2[a0.csV[0...n−2], where  a0:AP2[a0.csV[0...n−2]] = c if∃i(0≦i<n−1)(a0.csV[i] = c) else  a0:AP2[a0.csV[0...n−2]] = f   if[(∃i(0≦i<n−1)(a0.csV[i]= f ))     &(∀i(0≦i<n−1(a0.csV[i] = (f |ignore)))]   else a0:AP2[a0.csV[0...n−2]] = h. (7.3) Notice,a0.csV[n−1], which is the completion signal from a2, is not used here.We now present g_(i):suffix-body( ) and then discuss what it does. (7.4-i)  g_(i):suffix-body( ) = //executed by the parent-cell of a0:selectedPort.   [a0:AP2[a0.csV[0...n−2]] = a0.ccS;//signal c fromagent   a2 is excluded here.   // abandons protocol execution and stopsmessage   transmission if a0.ccS = h.   (a0.ccS= h)?( ){a0:resetPathway( ); a1.dc=true}    else true{ a1:ckSecurity&Proceed();}]  (7.4-ii)  a1:ckSecurity&Proceed( ) =   /* This is also executed bythe parent-cell of a0:selectedPort;    sets a1:csV to ignore insecureports and generates a    violation message for each such insecureport.*/   [∀j(0≦j<F:size( ))?( ){

a1:S(f_(j),a1.M)?   ( ){ a1.csV[j]=ignore;        a1:exception(f_(j));}}   //If all the functionPorts in F areinsecure, then abandons   protocol execution;    ∀j is used here as anenumerator.   (∀j(0≦j<F:size( ) & (a1.csV[j]=ignore))?( ){      a0:resetPathway( ); a1.dC=true}   else true{ a0:sendSignals( );    a1:activate&DeliverSignals( );}]  (7.4-iii)  a0:sendSignals( ) =//executed by the parent-cell  of a0:selectedPort.   [//initializes thesignals previously received from a2   and a3 to zero.    a0.csV[n−1]=0;a1.csV[m−1]=0;    /* if a0.ccS=c then switches memories, delivers c toeb.f₁ and     sets time stamp in the local time of eb.*/   (a0.ccS= c)?(){ a0:swMem( ); a0:s → a1;      a0:c → a2:c→ eb.f₁:timestamp( );}.  /*else, does not switch memories and delivers f to eb.   f₁ and setstime stamp.*/   else true{ a0:s → a1; a0:f → a2:f → eb.f₁:timestamp();}]  (7.4-iv) a1:activate&DeliverSignals( ) =   /* Also executed by theparent-cell of a0:selectedPort.    ∀j is used as enumerator. Activates   parent-cells of secure functionPorts,    if they are dormant.*/  [(∀j(0≦j<F:size( )){ (a1.csV[j]≠ignore)?( ) &       

f_(j):active?( ))?( ){ f_(j):activate( );}}    /*delivers signal s andsets time stamp in the local time of    the parent-cells of     secureports f_(j).*/    (∀j(0≦j<F:size( )){ (a1.csV[j]≠ignore)?( ){       a1:s→ f_(j):timeStamp( );}}    /*sets a1.dC=true, sends delivery-completesignal s to eb.f₂.      Sets time stamp in local time of eb.*/     a1:s→ a3:s → eb.f₂:timestamp( ); a1.dC=true;] (7.4)

Associating the same suffix-body with every g_(i)εG, simplifiescoordination of dynamic changes to the port-group G; ports may be addedto or deleted from G dynamically before new transactions begin. Let usnow consider what g_(i):suffix-body() does:

(7.4-(i)): If (a0.ccS=h) then the pathway is reset and a1.dC is set totrue. In this case, no message is sent. If (a0:ccS≠h) then C₀ begins toexecute the rest of the protocol starting with (7.4-(ii)) and at the endof this execution sets a1.dC=true. The following happens:

(7.4-(ii)): Security check is first performed and the vector a1.csV isupdated with ignore signals for insecure functionPorts and exceptions(messages notifying the security failure) are generated for the insecureports. If all functionPorts are insecure, then protocol execution isabandoned. Else, it continues.

(7.4-(iii)): First, resets the signals in a0:csV[n−1] and a1:csV[m−1]that were previously received from agents, a2 and a3. Agent a0 then doesthe following: If (a0.ccS=c) (see (7.3)) then the read/write memoriesare switched and a start signal, s, is sent to a1 and signal, c, isdelivered to eb.f1 via a2; else the read/write memories are notswitched, and a forward signal, f, is delivered to eb.f₁. and signal, s,is sent to a1. In either case, a signal delivery time stamp is set ateb.f₁ in the local time of eb. This time stamp is interpreted by the ebcell as the time of message dispatch. It is referred to by eb.t_(s) in(7.6) below. Since all eb cells are synchronized to a standardizedglobal time, this message dispatch time will be a global time.

(7.4-(iv)): The protocol first checks whether for each securefunctionPort f[j]εF, whether its parent-cell has been already activated.If not, it activates the parent-cell. Cell activation in TICC™-Ppde, isrelatively expensive. It takes about 2.5 to 3.0 microseconds to activatea cell in a 2-gigaHertz computer.⁷ This is the reason the statementdescribing this operation has been separated out in (7.3-(iv)).Normally, activation is done only once, the first time a signal isdelivered to a port. Separating this part out enables delivery signalsto be sent to all secure ports in quick succession. After sendingdelivery signals to all secure ports, delivers signal s to port eb.f₂via agent a3, with a time stamp and then sets a1:dC to true; ebinterprets this time stamp as the message delivery time, denoted byeb.t_(d) in (7.6). ⁷ The TICC™ subsystem that manages process andpthread activation was implemented by Mr. Rajesh Khumantham.

If CCPs are implemented as machine instructions, and hardware assist isavailable to set time stamps (as discussed in Section 8.1), then signalsmay be delivered to secure ports with less than 3 nanoseconds separationbetween successive ports in a 2 gigahertz CPU (estimated). For eachsecure functionPort f the signal delivery time stamp set at port f isthe local time of its parent-cell, which may not be synchronized to thestandardized global time. When message delivery is completed to allsecure ports, or if protocol execution is abandoned, a1.dC is set totrue. One may organize processing of the delivered message byparent-cells of functionPorts to begin only after a1:dC becomes true,i.e., after message has been delivered to all secure functionPorts. Thismay be implemented by modifying f:mR?() and g:pR?() as follows:

{

f:input=s & a1.dC=true

 (t)} [•→ f:mR?( )(t)]    {(true & f:state=S)(t′)} {

(g:input=s

 g:state=S) & a0.dC=true

(t)}[•→ g:pR?( )(t)]    {

true & g:input=φ & g:state=S

(t′)}. (7.5)

Meanwhile, when eb senses signal (c|f) at eb.f₁ and signal s at eb.f₂,at local times, eb.t_(s) and eb.t_(d), respectively, it installs thefollowing communicationEvents associated with the group-to-group messagedelivery into a growing causalnet:

C.g_(i) ^(S|F)(eb.t_(s)) for (0≦i<n), and

D.f_(j) ^(D)

(eb.t_(d)) for (0≦j<m)  (7.6)

as specified in equation (5.21), and after integrating them with thecausalnet, sends back completion signal c to both a0 and a1, byexecuting the protocols shown below, at eb.f₁ and eb.f₂, respectively:

(eb.f₁:c→a2:c→a0) and (eb.f₂:c→a3:c→a1).  (7.7)

All of this is done while parent-cells of functionPorts D_(j).f_(j) inFIG. 19 are processing the response to the service request that was justdelivered to them. Since no two eb cells install communicationEvents atthe same place in a growing causalnet, there will be no mutualinterference among different eb cells, when they perform theiractivities in parallel.

Since the eb cell has access to the virtualMemory it could access a1.csVand identify the functionPorts to which message was delivered. Using theALLEOPs it could determine the location in the growing causalnet wherethe event instances should be installed. Using these data the eb cellinstalls the communicationEvents into the causalnet.

The causalnet fragment that is so installed into the causalnet is shownin FIG. 20. Here dispatch times for g_(i) ^(s) for 0≦i<n−1 is set tot_(s), the time when signal was delivered to eb.f₁. Delivery times tofunctionPorts are nominally recorded as t_(d), the time when signal wasdelivered to eb.f₂. FIG. 21 displays the network installed for the replymessage transmission. The superscript ^(S) for g_(i) ^(S) and f_(j) ^(S)in FIGS. 20 and 21 will be ^(F) if message had been forwarded.

It may be noted, the message sending and message delivery eventinstances would have all been anticipated by the eb cell from itsknowledge of the ALLEOPs. Indeed, if anticipated event nodes do notappear with in a priori specified time limits, then an ea cell(EventAnalyzer cell, described below), that constantly monitors thegrowing causalnet, in parallel with the eb cells, would issue an errorreport to observers about a possible system failure. Since the eb cellhas access to the virtualMemory of the pathway tuned to eb.f₁ and eb.f₂,while installing the event instances, it could even check conditionsthat should hold true in the message sending and receiving cells, toverify that the relation R_((G,F)) (srm, rm) defined in Section 1.2.2holds true in the just completed transaction. However, this may undulydelay message transmissions and may not be practical at run time. Butthis can be done in a test mode.

When parent-cells of functionPorts in F, which received a servicerequest, sense message delivery signal at the functionPorts, f_(j), theyexecute the associated f_(j):tip() to send back a response message, bysending a (c|f) signal to a1. At this point, a1 would be expectingsignals only from port eb.f₂ and from all the secure functionPorts,since ignore signals had been already set in a1.csV for the insecureports. Protocol for sending (forwarding) back the reply message issimilar to the protocol shown in (7.1), (7.2a), (7.2b) and (7.4) withthe following differences: a1: selectedPort is set to the first secureport in a1.csV, i.e., the first port f_(j)εF for which a1.csv[j]≠ignore.No security checks are done for delivering the response to thegeneralPorts in G; every port in G receives the response.

During the transport of the response message, a1 sends signal s to a0and signal (c|f) to a3 only after it had received completion signalsfrom all secure ports D.f_(j) and completion signal from a3 as describedin (7.7). Agent a3 forwards signal (c|f) to eb.f₂, to inform eb that theresponse message is being dispatched to the generalPorts in G. Afterdelivering the response message to the generalPorts, a0 sends signal sto a2, which forwards it to eb.f₁, to inform eb that the responsemessage has been delivered back to the generalPorts in G. When eb sensesthese signals at both ports eb.f₁ and eb.f₂, it installs thecommunicationEvent instances shown in FIG. 21, for each secure f_(j), atappropriate places in the growing causalnet. After completing thisinstallation eb sends a completion signal c via eb.f₁ and eb.f₂ toagents, a0 and a1 using protocols shown in (7.7). The combined causalnetfragment of FIGS. 20 and 21 is shown in FIG. 22.

We have already discussed ndFSMs for agents, a0, a1 and ports g and f(see FIGS. 1 through 4). All agents and ports in sm-pathways areidentical 2-state ndFSMs. Clearly, the protocol is simpler forpoint-to-point communications, since there are no selected ports andai.csV for i=0, 1 will each have only two elements. The protocol uses atmost (6+m−1) CCPs, where m−1 is the number of ports in F. This does notcount the n−1 CCPs executed in parallel by the parent-cells ofC_(i).g_(i) to send completion signals to a0. Group-to-groupcommunications are relatively expensive, but still far cheaper thanconventional group-to-group communications.

As we said earlier, an application may have several eb cells in itsnetwork. No two eb cells will service the same sm-pathway. Besides ebcells, an application will also have several ea cells, EventAnalyzercells. The ea cells check for consistency of the growing causalnet withthe ALLEOPs, and look for occurrences of a priori specified eventpatterns in the causalnet to alert observers regarding thoseoccurrences. In most cases the watched for event patterns could bespecified by regular expressions that use ALLEOP nodes as terminalsymbols.

This kind of use of TICC™-Ppde calls for a practically unlimited supplyof processing units (CPUs). With the advent of multicore chips andnanotechnology the needed CPUs should soon become easily available.TICC™-Ppde not only provides a natural environment for using arbitrarynumbers of processing units, but also effectively makes use of availableprocessing units to build automatically the Self-Monitoring System (SMS)for each application. ALLEOPs specify event patterns that may occur,when an application is running. Deviations from specified patterns areconstrued as errors by the SMS. It is, of course, possible that eventpatterns in the causalnet could be correct, while computed values arewrong. However, this possibility is precluded by the correctness proofsgenerated during and after implementation, as discussed in Section 6.5.These features are unique to TICC™-Ppde.⁸ ⁸ At this point it isinteresting to speculate a bit. It is possible that some day we mightimplement software systems that “understand” what they do. We speculatehere capabilities such a software system should have in the context ofSMS in TICC™-paradigm. This will require that we incorporate into EventAnalyzer cells (ea cells) a general capability to learn patterns ofcausal chains that occur in causalnets and are of interest, based on aset of general seed patterns that are built into them. Learning willspecialize and refine the seed patterns. Ea cells may do this throughinteractions with their environments and interaction with applicationsthemselves. Ea cells also, of course, need a capability to representlearned patterns. They may use for this purpose the same kind of grammarthat was used to define the seed patterns. These grammars will useALLEOP nodes as non-terminal symbols. One may think of these patterns asabstractions of causalnets that specify activities that occur in anapplication and are of interest. One may even have an abstractionhierarchy of patterns of patterns. When a system recognizes occurrencesof these patterns, uses them to communicate and direct its owncomputations, and refines them, a system behavior might manifest that isakin to “understanding”. Capabilities of this kind are necessary tobuild systems that can diagnose and repair themselves. In the long runthey may lead to self-understanding software systems. The SMS inTICC™-paradigm provides a context to investigate problems in the designof such systems. We would like to hypothesize that our cerebral cortexdoes this kind of dynamic pattern analysis in our brains. Evolution hasendowed us with certain innate seed patterns, built into us: Patternsfor face recognition, voice recognition, odor recognition, motionrecognition, finger coordination, vibration sensing, hand/eyecoordination and leg/body coordination are examples of such seedpatterns. Recognized patterns dynamically govern the behavior oforganisms both internal and external, and also govern how the patternsthemselves are refined. Biologists would agree, these innatecapabilities, even in primitive forms, have had enormous influence onspecies survival. They are wide spread in varieties of insect and animalspecies. With learning, these innate capabilities are improved andspecialized and give rise to bewildering multitudes of manifestations wesee in Nature. Capacity to learn varies from species to species. When ahuman sees an image, events occur all over the human brain. We posit,recognition of the image seen is a continuing process, which occurs as aresult of dynamic identifications of on going patterns of causal chainsof events in the brain by the cerebral cortex, while the image is beingseen. Here, the identified patterns influence and direct the on goingrecognition processes, in parallel with those processes. These kinds ofrecognition processes cannot be described in terms of combinatorialaggregations of events or patterns, as many pattern recognition workshave approached this problem [Francis Crick, 47].

7.1. One-Way Ring-Streets

So far we have used the convention that replies are sent through thesame pathways through which service requests were sent. At times, thismay contribute to complicating the pthreads and increasing the number ofports attached to a cell, when different sequential computation arespawned by one cell in different other cells. It may also contribute todecreasing the efficiency of sequential computations. The modifiedDas-pathway in FIG. 23 avoids this problem (pathway augmentations forSMS, using eb and ea cells, are not shown in this figure, in order tokeep the figure simple).

Here, the ports in the generalPort group, G1, in FIG. 23 send theirjoint service request message to the ports in the functionPort group F1.When G1 does this its ports get reset to receive a reply. It willreceive this reply from the ports in F3. Ports in F1 receive the requestsent by the ports in G1, and send their joint reply, which could beviewed as another service request, to ports in F2. When F1 does this itsports get reset to receive the next service request message from G1.This clockwise passing of messages proceeds through the pathway loop inFIG. 23, until at the end ports in G1 receive the reply from the portsin F3. G1 may send its next service request to F1 only after it hadreceived this reply from F3. One may attach arbitrary numbers of agentsto the virtualMemory in FIG. 23. We refer to the modified Das-pathway inFIG. 23 as ring pathway since it has one virtualMemory and severalagents associated with it, organized into a ring. This arrangement isuseful to execute sequential computations in a parallel network. Cellsin any one group around the compound pathway work in parallel when theyprocess received messages.

8. Design for TICC™-CPUs in Multi-Core Chips

TICC™-Ppde simplifies designs for CPUs by eliminating the need for cachememories and the need to use speed up techniques, as explained inSection 5.6. However, TICC™-Ppde requires each CPU to provide somespecial facilities to run cells and execute communication protocols.These special facilities pertain to the following:

(i) Each CPU should contain a hardware clock to enable time stamping ofmessage deliveries to ports attached to the cell run by that CPU, timestamping being done at times when messages are delivered to the ports,messages being delivered in parallel to the ports of each cell. Since itis possible for message deliveries to multiple ports of a cell to occursimultaneously, it should be possible for the hardware clock to beinterrogated simultaneously by several ports of the cell, in order toset time stamps.

(ii) Each CPU should implement CCP (Causal Communication Primitive) as ahardware instruction.

(iii) Each CPU should contain interrupt handling facilities tocommunicate directly with the interruptPorts of the cell that the CPUruns, the CPU responding to detected interrupt signals only betweensuccessive TIP executions by that cell.

(iv) Each DMP (Distributed-Memory multi-Processor) with SMPs(Shared-Memory multi-Processors) as its computing nodes may contain aTICCNET™ interconnecting the SMPs. If DMP is integrated in a multi-corechip then the TICCNET™ may also be integrated in the chip. However, itis possible to dispense with the need for TICCNET™ in a multi-core chip,if the shared-memory organization described below that exploitsvirtualMemories is used.

These requirements do not complicate CPU designs, but do complicate chipdesigns. Simplified CPU designs increase achievable CPU densities inmulti-core chips.

8.1. Organization for Time-Stamping Message Deliveries

The organization described here facilitates time-stamping of messagedeliveries by a message delivering CPU, CPU_(D), (‘D’ for ‘Delivery’)using local times of the clock of CPU_(R) (‘R’ for ‘Receipt’) that runsthe cell whose ports receive messages that are being delivered. Sincemessages may be simultaneously delivered in parallel to ports of a cell,this organization facilitates simultaneous polling of clock times in themessage-receiving CPU_(R), by multiple message-delivering CPU_(D).

For each port C.p, tuned to virtualMemory C.p.vM, let C.p.clock andC.p.delivery be the addresses of two distinguished time registers inC.p.vM, and let C.cpu be the CPU that runs cell C. C.cpu broadcasts itsclock time to time register C.p_(i).clock of every port C.p_(i) for0≦i<n, attached to cell C. Each one of these C.p_(i).clock registerwould be, of course, in different virtualMemories, C.p_(i).vM. Tofacilitate this C.cpu should have access to registers C.p_(i).clock,C.p_(i).delivery, C.p_(i).state and C.p_(i).input in the virtualMemoryC.p_(i).vM, for every port C.p_(i) for 0≦i<n, at all times. Access toC.p_(i).state and C.p_(i).input is needed to evaluate guardsC.p_(i):mR?() and C.p_(i):pR?(), access to C.p_(i).delivery is needed tosort ports, and access to C.p_(i).clock is needed, of course, to setclock times. This is the only new requirement for this scheme to work.

Let us now suppose, port D.q of cell D is delivering a message to portC.p of cell C. Then D.q.vM=C.p.vM, and the protocol for message deliveryis executed by D.cpu. Suppose D.cpu was delivering the message to portsin a port-group G={C_(j).p|0≦j<m≧1}. Let C_(j).cpu be the CPU that runscell C_(j). Then, while D.cpu it is executing the protocol,D.q.protocol, it will have access to both time registers C_(j).p.clockand C_(j).p.delivery in the virtualMemory C_(j).p.vM=D.q.vM. Asdescribed in statements (8.4) of Section 8, when the protocol deliversthe message to port C_(j).p, D.cpu executes the method C_(j).p.timeStamp(), which does the following: It temporarily locks the registerC_(j).p.clock from getting updated by time signals being broadcast byC_(j).cpu, transfers the contents of C_(j).p.clock to the registerC_(j).p.delivery, and then unlocks the register C_(j).p.clock. Thus thetime register C_(j).p.delivery will always contain the delivery time ofthe latest message delivered to port C_(j).p. For any cell C_(j) for0≦j<m, let C_(j).p_(i) for 1≦i≦k_(j) be the other ports of C_(j) besidesC_(j).p. Then registers C_(j).p_(i).clock for 1≦i<k_(j) will all containidentical time, namely the time broadcast to all of them by C_(j).cpuand each pair of time registers C_(j).p_(i).clock andC_(j).p_(i).delivery will be in the distinct virtualMemoryC_(j).p_(i).vM. Let us suppose D_(i).q_(j) is delivering message toC_(j).p_(i) for 1≦i<k_(j). Then D_(i).q_(j).vM=C_(j).p_(i).vM andD_(i).cpu will have access to both registers C_(j).p_(i).clock andC_(j).p_(i).delivery while D_(i).cpu is delivering message toC_(j).p_(i). Thus, at the same time D.cpu is setting delivery time inC_(j).p_(i).delivery, for any or all i, 1≦i≦k_(j), D_(i).cpu, which isdelivering message to C_(j).p_(i), may set delivery time inC_(j).p_(i).delivery by moving the contents of C_(j).p_(i).clock toC_(j).p_(i).delivery, since both C_(j).p_(i).delivery andC_(j).p_(i).clock will be in D_(i).q_(j).vM and D_(i).cpu will haveaccess to both of them. This facilitates simultaneous access to theclock time of the clock in C_(j).cpu by the different message deliveringD_(i).cpu for 1≦i<k_(j).

8.2. Shared-Memory Organization that Exploits virtualMemories

Shared-memory organization, described below, for TICC™-CPUs inmulti-core chips uses virtualMemories to minimize memory interference,provide increased data security, increased execution efficiencies andeliminate the need for TICCNET™ in multi-core DMPs.

Each CPU in the multi-core chip will contain a small private memory ofno more than 16 mega-words. This private memory is intended to store thestate of the cell that is run by that CPU, state of the CPU and methodsand conditions defined in that cell. Other than this private memory, theCPU will have no dedicated main memory attached to it. However, each CPUwill have the capability to dynamically connect to a subset of acollection of independent hardware memorY modules, called Shared MemoryModules, SMMs, using programmable logic networks. The SMMs are kept in apool of such hardware memory devices associated with the chip. SMMs inthe pool have varying memory capacities ranging from 100 kilo-words to afew giga-words. Dynamic connections between the CPUs and SMMs arecontrolled by ports, as described later below.

Each virtualMemory in an application will have an SMM assigned to it byTICC™-Ppde, this assignment being done at compile time or run time. TheSMM assigned to a virtualMemory is never changed. The maximum number ofCPUs serviced by an SMM will be equal to the maximum number of cellsthat a cell-group may have. This is because, cells in a cell-group areall tuned to the same virtualMemory and thus all CPUs that run thosecells will use the same SMM. We assume here, the maximum number of cellsserviced by an SMM is likely to be no more than 16, which is the maximumlikely size of a cell-group.

Let C.p.smm be the SMM assigned to the virtualMemory C.p.vM. Weintroduce two machine instructions: Connect (C.ports) and Disconnect(C.ports), where C.ports is a set of all ports attached to cell CConnect (C.ports) connects C.cpu to C.q.smm for every port C.qεC.ports,and Disconnect (C.ports) disconnects C.cpu from C.q.smm for every portC.qεC.ports. When C.cpu is assigned to C, Connect(C.ports) is executed.When C releases C.cpu, Disconnect(C.ports) is executed.

We introduce two additional machine instructions: giveAccess(Ports) anddenyAccess(Ports), where Ports is a subset of ports appearing in aC.p:tip(). Of course, all ports in this subset would be attached to C.The instruction giveAccess(Ports) gives access to C.cpu to data(messages and methods) in C.q.smm for every port C.q E Ports only ifC.q.state=S, and denyAccess (Ports) removes the access rights to data inC.q.smm already given to C.cpu, for every port C.qεPorts. GiveAccess anddenyAccess are here implemented in hardware associated with the alreadyestablished connections to SMMs.

C.p:tip() Invocation & Execution Protocol: Let C.p.tipStart be thebeginning address of the memory area in which the compiled binary codefor C.p:tip() is stored. Let the value of C.p.tipInvoke be the beginningaddress of the memory area in the local memory of C.cpu, in which thecompiled binary code for the program segment,

  [C.p.input=φ; giveAccess(C.p.beginPorts);     eval(C.p.tipStart)],(8.1) is stored. For convenience, let us write these as,    C.p.tipStart:= [C.p:tip( )]    C.p.tipInvoke := [C.p.input=φ;Connect(C.p.beginningPorts);       eval(C.p.tipStart)]. (8.2)where “:=” is read as “beginning address of the compiled code of”. In(8.2), C.p.beginningPorts is a subset of all ports appearing inC.p:tip() such that for every C.q E C.p.beginningPorts, C.cpu shouldhave access to data in C.q.smm before evaluation of C.p:tip() begins.Finally, eval(C.p.tipStart) simply moves the instruction at the addressspecified by C.p.tipStart into the Instruction Register, C.cpu.IR, ofC.cpu, and moves the address C.p.tipStart to the Instruction AddressRegister, C.cpu.IAR, of C.cpu. When this is done C.cpu will startexecuting C.p:tip().

The values of C.p.beginningPorts and C.p.tipStart are determined atcompile time. We assume here TIPs would be compiled only after they havebeen completely refined. The compiled code for the right side of (8.2)is kept in the virtualMemory C.p.vM of port C.p at compile time. WhenC.cpu is assigned to cell C, this compiled code is copied into theprivate memory of C.cpu and C.p.tipInvoke is set, for every polled portC.p of cell C. This would be a part of cell activation. Let C.p.stack bea stack of maximum length 2. Normally it contains only one element, thetop element. Let C.p.stack[0] refer to the top element of the stack;normally C.p.stack[0]=C.p.tipInvoke.

After the state of C.p changes to S, and when C.cpu is ready to executeC.p:tip, it simply executes eval(C.p.stack[0]). This causes C.cpu tobegin executing the code on the right side of (8.2) which causes it toeventually execute C.p:tip() after it has acquired access to data in allneeded SMMs.

Ending C.p:tip() Execution: Let the value of C.p.tipEnd be the beginningaddress of the memory area in the local memory of C.cpu, in which thecompiled binary code for the program segment on the right in (8.3) isstored:

C.p.tipEnd:=[denyAccess(C.p.endingPorts);],  (8.3)

The value of C.p.endingPorts is also determined at compile time.C.p.endingPorts may be a superset of C.p.beginningPorts, since C.p:tip()may contain embedded TIPs. Compiled code for the program segment on theright of (8.3) is kept in C.p.vM at compile time and when C.cpu isassigned to C, the compiled code is copied into the private memory ofC.cpu, and C.p.tipEnd is set for all ports C.p attached to C. Whenexecution of C.p:tip() is completed, C.cpu executes eval(C.p.tipEnd).This removes all access rights given to C.cpu and terminates executionof C.p:tip(). The same invocation and execution protocol is repeatedlyused for every TIP embedded in C.p:tip(), the invocation and executionprotocols being suitably compiled in-line in the compiled code ofC.p:tip().

It may be noted, when C.p:tip() execution is completed, for allfunctionPorts C.q in C.p.endingPorts, C.q.state will be R, since sendingback a response is mandatory for functionPorts, unless of course therewas a programmed suspension of C.p:tip() execution (see below). For ageneralPort in C.p.endingPorts, its state may not be R, since it is notmandatory to send a response at a generalPort (see for example, the TIP(3.3) in Section 3).

Suspending and Resuming C.p:tip() Execution: It is possible to have aprogrammed suspension of C.p:tip() execution in the middle, and resumefrom where it was left off. Notice, there is a distinction betweenprogrammed suspension and suspension caused by an interrupt message: Inprogrammed suspension cell itself is not suspended only the TIPexecution is suspended. C.p.stack is used to do programmed suspensionand resumption as described here. The method, C.p:suspendTip() is usedfor programmed suspensions to suspend C.p:tip() execution in the middle.It should be embedded in-line into some pthread in C.p:tip(). It cannotbe activated through an interrupt message. It is usually used to suspendC.p:tip() execution based on conditions that may depend on the state ofcell C or one of its ports (see discussion following (5.5)).

At compile time the value of C.p.resumingPorts appearing in (8.4) is setas the set of ports C.q such that C.q.smm would be connected to C.cpu atthe time of suspension. C.cpu should be connected to the same set ofSMMs before it resumes execution of C.p:tip() from where it left off;hence the name, C.p.resumingPorts. C.p.tipResume specifies the beginningaddress of the compiled binary code of the program segment shown to itsright in (8.5) in the local memory of C.cpu. The compiled code for theright side of C.p.tipResume is kept in C.p.vM, for each C.p:suspendTip()that appears embedded in C.p:tip(), marking each such compiled code ofC.p:suspendTip() appropriately. When C.cpu is assigned to C, thecompiled codes corresponding to each C.p:suspendTip() appearing inC.p:tip() are copied into the private memory of C.cpu and C.p.tipResumeis set for each one of the compiled codes so copied into C.cpu. The laststatement in (8.4), sets C.p.stack[0]=C.p.tipResume, andC.p.stack[1]=C.p.tipInvoke. Thus, C.p.stack[0] and C.p.stack [1] are setat run time, when C.p:suspendTip() is executed.

When a programmed suspension of C.p:tip() execution occurs, C.cpu is notsuspended and released, but C.cpu simply proceeds to service the nextport in C:CIP(), after executing C.p:suspendTip(). When C.p is polled inan ensuing polling cycle of C:CIP(), it will evaluate to true, sinceC.p.input=s has been set in (8.4). After this happens, C.cpu will simplyexecute eval (C.p.stack [0]), which will move the instruction at theaddress specified by C.p.tipResume to the instruction register of C.cpu,which in turn will cause evaluation of C.p:tip() to resume from where itleft off, after popping C.p.stack, resetting C.p.input=φ and givingaccess to C.cpu to C.q.smm for every C.q in C.p.resumingPorts. Suchsuspension/resumption may occur repeatedly during a C.p:tip() execution.

It is possible that C.p is just one of the ports in a port-group,G=[C_(i).p,C₂.p, . . . , C_(n).p], C.p=C₁.p. Parent-cells of ports in Gconstitute a cell-group. Let C=[C₁, C₂, . . . , C_(n)] be thiscell-group. All the ports in G are tuned to the same virtualMemory,C.p.vM. Let G.vM=C.p.vM and G.smm=C.p.smm. Each port C_(i).p givesaccess to its parent-cell C_(i) to the virtualMemory G.vM afterC_(i).p.state=S becomes true. C_(i).cpu will get this access whenC_(i).p.stack[0] is executed and the access will get revoked whenC.p.tipEnd is evaluated. Access to G.smm and revocation of this accessmay not happen at the same time for all the CPUs in the set{C_(i).cpu|C_(i)εC}, since activities of cells in cell-group C may notbe synchronized to each other. Eventually, all CPUs in {C_(i).cpu|CiεC}will access same G.smm while each is executing C_(i).p:tip().

In this scheme, access to SMMs is given to CPUs dynamically, based oncomputational contingencies that arise in parallel computations. Thenumber of CPUs that may simultaneously access a SMM has been assumed tobe at most 16, but in most cases it will be between 1 and 4, sincecommon cell-group sizes are likely to be no more than 4. This reducesmemory interference in shared-memory operations. This also dramaticallyimproves data protection and security, since each port C.p gives accessto C.p.vM only to its parent-cell C and only at times when C.p.state isS, and message in virtualMemory C.p.vM is delivered to port C.p only ifC.p and the message satisfy a priori specified security requirements.

All methods pthreads and processes are activated in TICC™-Ppde onlythrough message deliveries. Thus, a cell may get activated, or accessand respond to a received message in a virtualMemory only if a prioridefined security requirements are satisfied. Also giving and revokingaccess rights to data in SMMs are built into hardware. There are nopthread or process activation directories; no Dynamic Link Libraries,DLLs. Thus, no unauthorized intruder can monitor which CPU is executingwhich pthread at what time and what messages are being exchanged. Datasecurity enforcement thus becomes a built-in feature of TICC™-Ppde atits innermost level in the shared-memory system with SMMs, and not afeature added-on to an operating system or an application. Thesecharacteristics erect practically impenetrable barriers against datatheft and system intrusions.

Problems in designing and implementing secure TICC™-based systems arenot in efficient, secure and reliable implementations of such systems,but in designing and defining a consistent set of message attributes,port attributes, virtualMemory attributes, security functions, andsecurity delegation/revocation protocols (where one port temporarilydelegates its security status to another port), which enforceapplication security. The problems here are no different from the usualproblems encountered in security system definitions, but problems ofreliable and correct implementation of a defined security system areeliminated. The valid attributes and security functions at the time ofmessage delivery are automatically invoked and used by communicationprotocols in applications (see footnote 16 and Section 8). Thus,efficient secure implementation of a defined security system isautomatic.

The SMM scheme complicates memory implementation, since it requires useof multiple shared-memory buses, one for each SMM, multiple memoryaccess networks in each CPU, and programmable logic networks toefficiently set up connections between CPUs and SMMs, and dynamicallychange access rights. The scheme, however, simplifies CPU designs, sinceCPUs do not have cache memories or any other speed-up ornamentation.Most importantly, the scheme contributes intrinsically to greaterefficiency, software security, privacy and protection. p.resumeStart isthe address in the compiled code of C.p:tip() at which C.cpu shouldresume operations. This is also set at compile time. C.p:suspendTip()performs, denyAccess(C.p.resumingPorts) and two other operations shownin the definition of C.p:suspendTip() below:

 void Port::suspendTip( ){denyAccess(this. resumingPorts);          this.input=s;           this.stack:push(C.p.tipResume);} (8.4)where this refers to the current port at which suspendTIP( ) is beingexecuted and  C.p.tipResume := [C.p.stack:pop( ); C.p.input=φ;      giveAccess(C.p.resumingPorts);       eval(C.p.resumeStart)] (8.5)

8.3. Using TICC™-Ppde to Design Asynchronous Hardware Systems

It is possible to use TICC™-Ppde for designing, refining, and formallyverifying asynchronous hardware systems that run with automatic SMS(Self-Monitoring System). Registers in hardware systems would becomevirtualMemories. Hardware subsystems may be encapsulated intocompound-cells, as illustrated in the example in Section 3.2, thecompound-cells hiding encapsulated components from other components in ahardware system, and each compound-cell having its own SMS. Suchcompound-cells may be used as hardware components that are plugged intolarger hardware systems in contexts where the external-ports of thecompound-cells are well-matched, as defined in Section 2.3.2, to portsof the larger system to which they are connected.

9. Concluding Remarks

What has been accomplished: We have introduced here a parallelprogramming paradigm which adapts and combines concepts from variousother paradigms. TICC™ provides the necessary glue for all of them towork together in TICC™-Ppde. TICC™-Ppde provides methods to (i) defineparallel processing TICC™-networks; (ii) abstractly specify interactionsamong ports in the networks using TIPs (Thread Interaction Protocols)and among cells in the networks using CIPs (Cell Interaction Protocols);(iii) complete implementations through successive refinements ofabstract specifications in TIPs; (iv) automatically derive ALLEOP modelsfrom TIPs and refinements of TIPs; (v) automatically derive traces fromALLEOPs using action characterizations; (vi) automatically buildECT-networks (Event Characterization Table networks) from traces (vii)use ECT-networks to produce interactive proofs of valid properties ofimplementations, stated as CTL-assertions, both at the FSP and NFSPlevels; (viii) automatically incorporate run-time SMS (Self-MonitoringSystem) into every completed implementation; (ix) perform limit testingand ad hoc synchronization and coordination; (x) use arbitrarily largenumbers of parallel processing units; and (xi) provide abstractionsneeded to develop and run parallel programs in multi-core chips.

On Communications and Computations: TICC™ defines high-speed computingmechanisms for communications. Computations performed by thecommunication mechanisms are integrated with parallel processingcomputations performed by cells. Mechanisms for synchronization,coordination, security enforcement and self-monitoring are built intothe communication mechanisms. For each message exchange one can predictwithin tight bounds when the message sending event might begin and whenthe message would be delivered, based on the history of messageexchanges available in the causalnet that is built by the SMS.Similarly, for each action event the time it might begin execution andthe time it would complete execution are predictable within reasonablytight bounds, based on the history in the causalnet. It is not possibleto do these in Actor systems or in π-calculus.

Communication is integrated with computations in a manner that isanalogous to CSP, but with much greater flexibility, power and mutualisolation of message processing parallel computations and communicationprotocol computations performed by the same cells, and mutual isolationof asynchronous parallel cells that communicate with each other, also inparallel. TICC™-Ppde programs are self-synchronizing, self-coordinatingand self-activating. They do not require monitors, semaphores,schedulers, synchronizers, coordinators, serializers or any otherornamentation to make a parallel program work correctly.

On Interaction Specifications: A common feature of TICC™-Ppde andπ-calculus is that they both specify parallel computations throughinteractions among computing components. This the only common featurebetween the two. The interaction mechanisms are quite different.

Each π-calculus Agent runs in parallel with other Agents. The onlycomputing operations performed by π-calculus Agents are: Namesubstitutions for parameters defined in an Agent, exchanging namesbetween pairs of Agents via links, dynamically establishing linksbetween Agents, and hiding links. Π-calculus does not, however, specifycomputing mechanisms needed for communicating names via links. Indeed,the needed mechanisms cannot be specified in the π-calculus formalism.Communicating names via links is assumed as a given primitive. There isno concept of refinement, but hiding should enable encapsulation. It isnot clear though, what the criteria would be to find matching ports toplug-in an encapsulated component into a larger system.

Each TICC™-Ppde cell runs in parallel with other cells. TIPs specifyinteractions among ports attached to cells. Interactions specified byTIPs describe two kinds of computations, both conventional sequentialcomputations: (i) computations performed by a cell to process and buildmessages and (ii) computations performed by the same cell to sendmessages it builds through its ports to other cells. TIPs isolate thetwo computations from each other. TIP computations may be specified atan abstract level, and reduced to their final implementations throughprogressive refinements. Subsystems may be encapsulated into compoundcells and used as plug-in components, with a well defined criterion toconnect with matching ports in a larger system.

On Verification Model based verification of design specifications usingFSP [15] and CTL [40-44] have played significant and important roles insystem design. They are needed to verify designs and validate propertiesthat implementations should satisfy. The problem with FSP is, abstractFSP specifications cannot be directly reduced to implementations throughsuccessive refinements. This makes it necessary to verifyimplementations using different tools, and this task is more complex,than design verification.

Model based verification by Clark et al [38-40], [Emerson, 41] verifysynchronous hardware design specifications, not hardwareimplementations, because issues of coordination and race-conditions donot seem to be a part of the verification system. Nevertheless,verification methods introduced by Clark et al are widely used byhardware designers to validate designs. There are hardware descriptionlanguages like GEZEL [Schaumont, et al, 46] which allow design andverification of race free hardware systems. It is not, however clear,whether they are being widely used. TICC™-Ppde specification methodologymay be used to specify and verify implementations of race-freeasynchronous hardware systems. All timings, synchronization andcoordination requirements of an implementation are implicitly a part ofspecifications. They are taken into account during verification. Theonly restriction is, components should interact asynchronously. This maymake TICC™-Ppde not suitable to verify clock pulse driven synchronoushardware designs.

The advantage of using TICC™-Ppde is that abstract specifications ofintended computations look somewhat similar to FSP specifications ofabstract designs, and TICC™-Ppde provides a methodology to reduce theabstract designs directly to implementations through successiverefinements. TICC™-Ppde makes it possible to use model based formalverification to validate implementations at any stage of refinement.Besides providing such verification capabilities, the TICC™-paradigmautomatically incorporates the SMS into completed implementations tomonitor performance throughout the life time of applications, whetherhardware or software, as long as components interact asynchronously anduse communication mechanisms based on CCP-driven signal exchanges.

On Abstractions in TICC™-Ppde: Abstractions introduced by theTICC™-paradigm are not really programming abstractions, even though wehave used the phrase programming abstractions in this paper.TICC-Network, Cell, Port, Agent, VirtualMemory and Pathway areabstractions of system components, and pthread, TIP, CIP, ALLEOP andCausalnet are process abstractions. TICC™-Ppde provides a programmingframework for specifying and/or deriving these abstractions. They aredistinct from conventional-programming-abstractions such as variables,blocks, assignments, declarations, conditional statements, while-loopsand data-structures, conventional-process-abstractions like methods,functions and sub-routines, and conventional-component-abstractions suchas class, object and message. Conventional-programming-abstractions andconventional-process abstractions do not directly identify and relate tosystem components and processes as TICC™-Ppde abstractions do.Conventional-component-abstractions do abstract system components, butmapping classes to system components in implementations is quite anon-trivial task.

On System Design and Implementation: TICC™-Ppde shifts the focus ofsystem development from programming to system decomposition, interactionspecification and verification. Programming through refinements becomesa trivial task once system organization and interaction specificationsare in place, and verification follows as a natural consequence of theimplementation. At present, we do not have systematic methods for systemdecomposition. One faces this problem in the specification of anycomplex system, software or hardware, and physical or social systems.Perceived realizability conditions always influence system decompositionand design. Allowing realizability conditions that depend on programmingidiosyncrasies to guide system decomposition and design is, however, nota good practice. By shifting the focus to system decomposition andinteraction specification, and delegating programming to successiverefinements of an already defined design, TICC™-Ppde attempts to avoidthis problem.

Modes of interactions between software/hardware components in theTICC™-paradigm are not the same as they are in conventional softwaresystems, time sliced concurrent software systems, π-calculus frameworkor synchronous hardware systems. Designing TICC™-networks, defining TIPsand CIPs, developing logical characterizations of pthreads andidentifying CTL-assertions to be validated are important and difficultproblems. Expertise in programming will not help solve these problems.TICC™-paradigm calls for new approaches to the way system designers andprogrammers should be trained; they should be trained in componentinteraction analysis, logic and verification techniques. We hope,methods for interaction analysis and concepts of optimal system designsexpressed in terms of TICC™-networks and interactions, will emerge. Theyare necessary.

Projects: Some of the projects enumerated here are long term projects(marked LT), requiring 5 to 10 years to complete, and some are shortterm projects (marked ST) requiring only 3 years to complete.: Theprojects are the following: (i) developing new compilers compatible withTICC™-Ppde (ST); (ii) implementing TICC™-CPU designs incorporatingrequirements specific to TICC™-Ppde, discussed in Section 10 (ST); (iii)designing and verifying asynchronous self-monitoring hardware systemsusing TICC™-Ppde (ST); (iv) incorporating self-diagnosis, self-repairand learning capabilities into SMS (LT); (v) defining and analyzingrelationships between ALLEOPs and FSPs (LT); (vi) developing TICC™-Ppdecompatible principles of software/hardware engineering and training ofprogrammers (LT); (vii) implementing TICCNET™ (ST); (viii) Implementinginteractive ALLEOP-proof methods (ST). (ix) Providing graphical userinterfaces that facilitate TICC™-Ppde based system design,implementation and verification (ST). (x) Implementing TICC™-OS, aTICC-based parallel operating system (ST). (xi) Creating an internetinterface, TICC™-Browser (ST). (xii) Using SMS for pattern recognitionand learning based on dynamically recognized event patterns in acausalnet (LT). (xiii) Using SMS to dynamically control behavior of anapplication based on recognized event patterns in a causalnet (LT).(xiv) Building secure massive efficient TICC™-based parallelapplications in medical information systems, intelligence informationsystems, business information systems, knowledge based systems, naturallanguage understanding systems, complex physical simulations, weatherprediction, etc., (LT).

Significance: The goal of realizing a high quality, secure and fullyoperational TICC™-Ppde is with in reach using on IV currently availabletechnologies. Proof of concept prototype implementations of TICC™ andTICC™-Ppde substantiate this claim. There is no need to develop newtechnologies to realize this goal; it can be realized with in threeyears, if enough resources are devoted to it. Realization of this goalis likely to profoundly impact the way individuals use their desk-topand lap-top computers, the way computers are used in scientific andtechnical applications, the way social, educational, business,governmental organizations use computers, and the way softwareindustries produce and market software. Eventually new regulatorystandards for marketing validated software might emerge. Eventually, wemay produce complex validated secure self-correcting software thatoperate independently in space based and terrestrial robotic systems aswell as personal, business, governmental, social, scientific andeducational computers, in all cases protecting users against invasionsof privacy and malicious attacks.

We have introduced here a system architecture that sets a basis for anew era of computing technology to evolve.

Appendix I OG-Solution: TIPS, ALLEOPs and Traces

Environment Cell:  E.i:TIP( ) =  [(i:mR?( )& g:pR?( )){g:s( );/*Startsall cells*/       i:s( );/*acknowledges to user*/} (I.1) EntranceTurnstile Sensors:  Se[j:0...1].f:TIP( ) =   (Se[j].f:personAtGate?( ) &Se[j]f:mR*?( )){   Se[j].g:s( );//signals Et[j].f_(t)    Se[j].g:pR?()*{Se[j].g.personAtGate=false;}} (I.2)When a person approaches a gate (turnstile) the sensor at the gate setsSe.g.personAtGate=true. After letting a person into the park or afterdenying entry to the person because the park is full, the person leavesthe gate. At that point, the functionPort, Et[j].f_(t), of the entranceturnstile sends back reply to Se.g. When sensor receives this reply itresets Se.g.personAtGate to false. It will become true again when thenext person gets to the gate. Thus, a second person may enter only afterthe first person has left the gate.

Entrance Turnstiles: Et[j:0...1].f_(t):TIP( ) =  /*On sensing the signalat Et[j].f_(t), Et[j] signals the counter C via pathway,   Et[j].g

 C.f[j]. After doing this, waits for response from C by performing the  non-deterministic polling below.*/.  [Et[j]:personEntering?( ) {//receives signal from Se[j].g, see (I.4)   Et[j].g:s( ); //signals C.f[j]to get entry permission.   //Waits for response.   (∃(p)(p = (Et[j].g |Et[j].f))p:mR?( ))*{    selectOne{ (p=Et[j].g)?( ){Et[j].g:letPersonIn();}       (p=Et[j].f)?( ){Et[j].f:denyEntry( ).s( );}}    /*when Et[j].gbecomes ready to send signal sends reply signal to Se[j].g.*/    Et[j].g:pR?( )*{ Et[j].f_(t):s( );}} (I.3) Definitions:Et[j]:personEntering?( )

 Et[j].f_(t).input = s      

 Et[j].f_(t):mR?(

Et[j].f_(t) ^(D)

[T(Se.g,1)]) (I.4) This predicate is being used for discourseconvenience. It is true only if a signal has been delivered toEt[j].f_(t) by Se[j].g and Et[j] has sensed that signal. WhenEt[j].f_(t) replies to Se[j].g, after responding to the person at thegate, Et[j]:personEntering?( ) automatically becomes false, sinceEt[j].f_(t).input = s will no longer be true. { Et[j].g:mR?( )*}[•→Et[j].g:letPersonIn( )]{Et[j]:personInPark?( )} (I.5) {Et[j].f:mR?()*}[•→ Et[j].f:denyEntry( )]           {

Et[j]:personInPark?( )} (I.6) Exit Turnstiles Sensors:Sx[j:0...1].f:TIP( ) =  Sx[j].f:personAtGate?( ){    Sx[j].g:s();//signalsXt[j].f_(t)    Sx[j].g:pR?( )*(Sx[j].g.personAtGate=false;}}(I.7) Exit Turnstiles: Xt[j:0...1].f_(t):TIP( ) = (Xt[j]:personLeaving?( ){ Xt[j].g:s( );}//signals Xt[j].f_(t)           Xt[j].f_(t):mR?( )){            Xt[j].g:s( );/*signalscounter*/.            Xt[j].g:mR( )*{letpersonLeave( );}           Xt[j].f_(t):s( );} (I.8) Definitions: (Xt[j].f_(t):mR?( )}[•→Xt[j].g:letPersonLeave( )]         {

Xt[j].g:personInPark?( )} (I.9)  Xt[j]:personLeaving?( )

 Xt[j].f_(t).input = s     

 Xt[j].f_(t):mR?(

Xt[j].f_(t) ^(D)

[T(Sx.g,1)]) (I.10) counter: When cell C starts operations, counter isinitialized to zero and max is set to a value > 0. C increments thecounter on sensing signals at ports C.f[j:0...1], if there is room inthe park, i.e., counter.count < max, and responds to Et[j].g via C.f[j]

Et[j].g giving permission to enter, else C sends response via C.g[j]

Et[j].f to deny entry, then waits for response and then acknowledgessignal received through C.f[j]. C.f[j:0...1]:TIP( ) =  C.f[j]:mR?( ){//senses notice from Et[j].g that a person is trying to enter.   /*increments counter if counter.count < max)?( ) is true, thenpermits entry by    sending back a signal to Et[j].g; this alsoacknowledges the signal received    above from Et[j].g.*/  (counter.count < max)?( ){ counter++; C.f[j]:s}   /*else, denies entryby sending signal to Et[j].f from its port C.g[j].   Does not yetacknowledge signal received from Et[j].g.*/         else true{ C.g[j]:s();   /*on receipt of acknowledgement from Et[j].f sends backacknowledgement for    signal received earlier from Et[j].g */  C.g[j]:mR?( )*{ C.f[j]:s( );}} (I.11) Decrements counter on sensingsignals at ports C.f[j:2...3], and responds to Xt[j].g allowing theperson at the gate to leave. C.f[j:2...3]:TIP( ) = C.f[j]:mR?( ){      counter−−; C.f[j]:s( );} (I.12) Sends out counter.count to thedisplay unit on sensing signal at C.f[4]. C.f[4]:TIP( ) =  C.f[4]:mR?(){C.f[4]:make(C.f[4].rd:msg( ).count=counter.count);       C.f[4]:f( );}(I.13) Definitions: {counter.count < max)?( )}[•→ counter++]        {counter.count ≦ max)?( )} (I.14) {counter.count ≦ max)?( )}[•→counter−−]         {counter.count < max)?( )} (I.15) Display Unit: Onsensing signal at its InterruptPort forwards request for count tocounter. Displays the count when it is received. D.i:TIP( )=  D.i:mR?(){ D.i:s( ); D.g:f( );      D.g:mR?( )*{ D.g:displayCount( ).s( );}}(I.16) Definitions: (D.g:mR?( )* & (∃(integer c)(D.g:rd.msg( ).count=c)}  [•→ D.g:displayCounT( )]{D.g.rd:msg( ).count=c} (I.17) POLLING CYCLES:Ignoring interruptPorts, except for the display unit. E:Polling():[E.i:mR?( ) → E:Polling( )] (I.18) Se[j]:Polling( ):  [Se[j].f:personAtGate?( ) → Se[j]:Polling( )] (I.19) Sx[j]:Polling( ):  [Sx[j].f:personAtGate?( ) → Sx[j]:Polling( )] (I.20)Et[j:0...1]:Polling( ):     [Et[j].f_(t):mR?( ) → Et[j]:Polling( )](I.21) Xt[k:0...1]:Polling( ):     [Xt[k].f_(t):mR?( ) → Xt[k]:Polling()] (I.22) C:Polling( ):   [C.f[0]:mR?( ) → C.f[1]:mR?( )→ C.f[2]:mR?( )→   C.f[3]:mR?( ) → C.f[4]:mR?( ) → C:Polling] (I.23) D:Polling( ):[D.i:mR?( ) → D:Polling( )] (I.24) It is not necessary to define theCIPs for the cells, since they should be obvious. From the abovedefinitions, the system computes the following ALLEOPs and Traces.ALLEOPS: Et[j:0...1]:ALLEOP( ): Et[j:0...1]:ALLEOP( ) =    [Et[j].f_(t):ALLEOP( ) •→ Et[j]:ALLEOP( )] (I.25)Et[j:0...1].f_(t):ALLEOP( ) =  [Et[j]:personEntering?( ){   Et[j].g^(S)[T(Et[j].g,0)]> →    (

C.f[j]^(D)

[T(Et[j].g,1)] || →...→ C.f[j]:ALLEOP(...)) •→     //puts here thealternates from the non-deterministic polling     (Et[j].g:mR?(

Et[j].g^(D)

[T(C.f[j],1)])*{       Et[j].g:letPersonIn( )} |     Et[j].f)mR?(

Et[j].f^(D)

[T(C.g[j],1)])*{       Et[j].f:DenyEntry( ) •→       //acknowledgesreceipt of signal at Et[j].f       Et[j].f^(S)[T(Et[j].f,0)] →       (

C.g[j]^(D)

[T(Et[j].f,1)]       ||[C.g[j]:mR?(

C.g[j]^(D)

[T(Et[j].f,1)])* •→...•→)})}   •→ Et[j].g:mR?(

Et[j].g^(D)

[T(C.f[j],3)])*{    Et[j].f_(t) ^(S)[T(Et[j].f_(t),0)]    (→

Se[j].g^(D)

[T(Et[j].f_(t),1)]]    ||[Se[j].g:pR?(

Se[j].g^(D)

[T(Et[j].f_(t),1)])•→...•→])}] (I.26) Xt[j:0...1]:ALLEOP( ):.Xt[j]:ALLEOP( ) = [Xt[j].f_(t):ALLEOP( ) •→ Xt[j]:ALLEOP( )] (I.27)Xt[j].f_(t):ALLEOP( ) =  [Xt[j]:personLeaving?( ){  Xt.g^(S)[T(Xt[j].g,0)] → /*delivers signal to C.f[j+2]*/   (

C.f[j+2]^(D)

[T(Xt[j].g,1)] ||→...→ C.f[j+2]:ALLEOP( ))}   //on sensing receivedsignal, after count has been decremented.   Xt[j].g:mR(

Xt[j].g^(D)

[T(C.f[j+2],1)])*{           Xt[j].g:letPersonLeave( )}   Xt[j].f_(t)^(S)[T(Xt[j].f_(t),0)]]   → (

Sx[j].g^(D)

[T(Xt[j].f_(t),1)]]       || Sx[j].g:mR?( )*{ •→...•→}) (I.28) C ALLEOP(): Counter ALLEOPs C:ALLEOP( ) =   [C.f[0]:ALLEOP( ) •→ C.f[1]:ALLEOP( )•→ C.f[2]:ALLEOP( )    •→ C.f[3]:ALLEOP( ) •→ C.f[4]:ALLEOP( )    •→C:ALLEOP( )] (I.29) C.f[j:0...1]:ALLEOP( ) =  [C.f[j]:mR?(

C.f[j]^(D)

[T(Et[j].g,1)]){   ((counter.count < max){ counter++ •→    C.f[j]^(S)[T(C.f[j],0)] →     (

Et[j].g^(D)

[T(C.f[j],1)] //Et[j].g senses signal immediately      ||Et[j].g:mR?(

Et[j].g^(D)

[T(C.f[j],1)])*{•→...•→}           •→...•→ )} |   

(counter.count < max){ counter−− •→     C.g[j]^(S)[T(C.g[j],0)] →     (Et[j]f^(D)[T(C.g[j],1)] //Et[j].f senses signal immediately     ||Et[j].f:mR?(

Et[j].f^(D)

[T(C.g[j],1)])*{•→...•→}            •→...•→ )     •→ C.g[j]:mR?()*{//waits for response from Et[j].f.      //sends back acknowledgementto Et[j].g for signal received at C.f[j]      C.f[j]^(S)[T(C.f[j],2)] →     (

Et[j].g^(D)

[T(C.f[j],3)]      //Et[j].g senses acknowledgement immediately.    ||Et[j].g:mR?(

Et[j].g^(D)

[T(C.f[j],3)])*{               •→...•→})}}] (I.30) C.f[j:2...3]:ALLEOP() =  [//senses person leaving signal from Xt[j−2].g.   C.f[j]:mR?(

C.f[j]^(D)

[T(Xt[j−2].g,1)]){ counter−−    •→ C.f[j]^(S)[T(C.f[j],0)] //responds toXt[j−2].g    → (

Xt[j−2].g^(D)

[T(C.f[j],1)]     //Xt [j−2] waits for response from C.f[j] and takesappropriate action.     ||Xt[j−2].g:mR?(

Xt[j−2].g^(D)

[T(C.f[j],1)])*{                •→...•→})] (I.31) C.f[4]:ALLEOP( ) = [C.f[4]:mR?(

C.f[4]^(D)

[T(D.g,1)]){      •→ C.f[4].rd:make(f[4]:msg( ).count = counter.count)     •→ C.f[4]^(F)[T(C.f[4],0)//forwards message      → (

D.g^(D)

[T(C.f[4],1)]        //D waits for response from C.f[4] and takesappropriate action.        || D.g:mR?(

D.g^(D)

[T(C.f[4],1)])*{                •→...•→})}] (I.32) D:ALLEOP( ): DisplayUnit ALLEOPs. U here is the external user who requests the count.D:ALLEOP( ) = [D.i:ALLEOP( ) •→ D:ALLEOP( )] (I.33) D.i:ALLEOP( ) = [D.i:mR?(( D.i^(D)

[T(U.g,1)])*{   D.i^(S)[T(D.i,0)] → U.g^(D)[T(D.i,1)]//acknowledgesuser's signal   •→ D.g^(F)[T(D.g,0)] //requests count    → (

C.f[4]^(D)

[T(D.g,1)] || →...→ C.f[4]:ALLEOP( ))    //displays count on receipt ofresponse.   •→ D.g:mR?(

D.g^(D)

[T(C.f[4],1)])*{D.g:displayCounT( )} (I.34) Notice, in (I.35) no replyis needed for message received through D.g. The combined ALLEOP for theOG-Solution is:  O-Garden:ALLEOP( ) =   □(Et[0]:ALLEOP( ) ||Et[1]:ALLEOP( ) || D:ALLEOP( )||      Xt[0]:ALLEOP( )|| Xt[1]:ALLEOP( )|| C:ALLEOP( ))] (I.35)TRACES: The traces are presented in the ECT-Blocks in Tables 5.1 through5.3 and Table 6.1 and 6.2. The corresponding ECT-networks are presentedin Tables 5 and 6. See discussion in Section 6.1.

APPENDIX II PC-Solution: TIPs, CIPs, ALLEOPs and Traces

Here we describe the implementation by defining the CIPs for all cellclasses in the implementation. It is more convenient to do so in thisexample. It shows a different style of defining an implementation.

Producer CIP & TIP: After initialization, in each polling cycle,producer P[j] looks for a signal at its interruptPort, P[j].i. If thereis a signal at P[j].i then P[j] terminates its operations. Otherwiseproceeds to poll its port P[j].f, produces a new product every time itsenses a signal at P[j].f and sends it off to port D.g[j] of thedistributor, as defined in P[j]:tip( ) in (II.2).  void Producer::CIP(){   initialize?( ){i:s( ); stopPolling=initialize = false;}   while (

stopPolling){ i:mR?( ){stopPolling=true; i:s( );}           f:mR?(){f:tip( );}}     prepareToTerminate( );} (II.1)  P[j].f:TIP( ) =[P[j].f:mR?( ){ P[j].product =                 P[j]:produceProduct( );            P[j].f.wr:msg( ).contents = P[j].product);            P[j].f:s( );}}] (II.2) Definition:  ∃(t₀<t₁){

P[j].f:mR?( )

(t₀)}       [•→ P[j].product=P[j]:produceProduct( )(t₀)]      {∃(Productp)(P[j].product = p)(t₁)} (II.3) Consumer CIP & TIP:  voidConsumer::CIP( ){ /*During initialization each consumer, C[j] for 0≦j<m,writes an empty package into the readMemory of its port C[j].g and sendsit off to the distributor port D.f[j] in order to request a new product.Notice, the package in its readMemory is received in the writeMemory ofD.f[j]. In its while-loop C[j] terminates itself on receipt of a messageat its interruptPort, C[j].i. Else, receives a new product throughC[j].g and when the product is used up, sends off the empty package inits readMemory to the distributor port D.f[j] in order to requestanother new product. Distributor D receives the empty package in thewriteMemory of its port D.f[j]. On receipt of this empty package, Dsearches for a new product, puts it into the package in the writeMemoryof D.f[j] and sends it off to C[j].g. The package is repeatedly used bythe consumer to request and receive products.*/   initialize?( ){i:pR?(){i:s( )}; stopPolling=initialize=false;             g.rd:make(package,contents= φ); g:s( );}   while (

stopPolling){ i:mR?( ){stopPolling = true; i:s( );}              g:mR?(){g:tip( );}}   prepareToTerminate( );} (II.4)  C[j].g:TIP( ) =[C[j].g:mR?( ){C[j]:pickUp( );         /*Sends out a request for a newproduct only if stopPolling is false.*/         (

stopPolling?( ) &          C[j]:usedUp?( )*){C[j].g:s( );}}] (II.5)Definitions:  [∃(t₀ < t₁)∃(Product p)    {

C[j].g:msg( ).contents=p

(t₀)} [•→ C[j]:pickUp( )(t₀)]    {

C[j].hasProduct = p &     C[j].g:msg( ).contents = φ

t₁)}] (II.6) C[j].hasProduct is an attribute defined in the Consumerclass. C[j]:usedUp?( ) in (II.5) has to be defined in the Consumer classby the designer, in a suitable manner. Distributor CIP & TIP:  voidDistributor::CIP( ){//n is the number of producers.   initialize?(){i:pR?( ){i:s( );}//acknowledges activation       stopPolling=initialize=false; //initializes itself        g:s();//activates all producers and consumers; see network in Figure 12. /*Writes an empty package in the readMemory of each one of its portsD.g[j] for 0≦j<n and  sends it off to the functionPort, P[j].f, ofproducer P[j] to place an order for a new  product. P[j] receives thisempty package in the writeMemory of P[j].f. On receipt of  this order,P[j] produces a new product, puts it into the package in the writeMemoryof  P[j].f and sends it off to D.g[j]. */        for (int j=0; j < n;j++;){         g[j].rd:make(package, contents=φ); g[j]:s( );}}   while(

stopPolling){  /*On receipt of an interrupt signal, sends terminationsignal to all consumers and sets stopPolling  to true.*/   i:mR?( ){stopPolling = true; g:s( ); i:s( );}   consumerServiced = false;D.sortedPortsList:clear( );   D.sortedPortsList:clear( );  /*Consumersare serviced in the order requests are received from them.*/    for (intj = 0; j < m; j++){      f[j]:mR?(){D:sortInto(D.f[j],D.sortedPortsList);}    for (int i = 0; i <D.sortedPortsList:size( ); i++){      D.sortedPortsList[i]:tip( );consumerServiced = true;} /*If an interrupt signal was received theni:mR?( ) will still be true. In this case, if consumerServiced is false,i.e. no consumer was serviced in the current polling cycle, thenterminates itself after receiving response from all consumers andproducers indicating that they have terminated. If there was a consumerthat was serviced then repeats the polling cycle, until there are nomore consumers to be serviced.*/    (stopPolling?( ) &

consumerServiced?( )){        g:pR?( )*{prepareToTerminate( )}}}} (II.7) D.f[j:0...m−1]:TIP( ) = [D.f[j]:mR?( ){     (∃k(0≦k<n)D.g[k]:mR?( ))*{       D.g[k]:moveProduct(D.f[j]);       D.g[k]:s( );D.f[j]:s( );}}](II.8) Definitions: {

∃(x)(x = D.g[k]:msg( ).contents

(t₀)}      [•→ D.g[k]:moveProduct(D.f[j])(t₀)]   {

D.f[j]:msg( ).contents = x &    D.g[k]:msg( ).contents = φ

(t₁)} (II.9) ALLEOPs: In the ALLEOPs below, for simplicity, we ignoreall interruptPort polling, interrupt message processing and terminationprocesses. Consumer C[j:0...(m−1)] ALLEOP:  C[j:0..m−1]:ALLEOP( ) =   [C[j]:INIT-ALLEOP( ) •→ C[j]:BODY-ALLEOP( )] (II.10) C[j]:INIT-ALLEOP( ) =    [C[j]:initialize?( ){      stopPolling = false•→ initialize = false      •→ C[j].g.wr:make(package, contents = φ);     •→ C[j].g^(S)[t(C[j].g,0)]//sends out a request for a product.     → (

D.f[j]^(D)

[t(C[j].g,1)] || D:BODY-ALLEOP( ))}] (II.11)  C[j]:BODY-ALLEOP( ) =    [

C[j]:stopPolling?( ){C[j].g:ALLEOP( )            •→ C[j]:BODY-ALLEOP()}] (II.12)  C[j].g:ALLEOP( ) =    [C[j].g:mR?(

C[j].g^(D)

[t(D.f[j],1)]){     g:pickup( ) •→ C[j]:usedUp?( )*{g^(S)[t(C[j].g,2)]    → (

D.f[j]^(D)

[t(C[j].g,3)] ||D:BODY-ALLEOP( ))}}] (II.13) Producer P[j:0...(n−1)]ALLEOP:  P[j]:ALLEOP(...) =    [P[j]:INIT-ALLEOP( ) •→ P[j]:BODY-ALLEOP()] (II.14)  P[j}:INIT-ALLEOP( ) =    [P[j]:initialize?( ){    stopPolling=false •→ initialize=false}] (II.15)  P[j]:BODY-ALLEOP( )=     [

P[j].stopPolling?( ){P[j].f:ALLEOP( )             •→ P[j]:BODY-ALLEOP()}] (II.16)  P[j].f:ALLEOP( ) =   P[j].f:mR?(

P[j].f^(D)

[t(D.g[j],1)] |

P[j].f^(D)

[(t(D.g[j],3)]){     •→ P[j].product = produceProduct( )     •→P[j].wr:msg( ).contents = P[j].product)     •→ P[j].f^(S)[t(P[j].f,0)]    → (

D.g[j]^(D)

[t(P[j].f,1)] ||D:BODY-ALLEOP(...))}] (II.17) Distributor ALLEOP: D:ALLEOP(...) = [D:INIT-ALLEOP( ) •→ D:BODY-ALLEOP( )] (II.18) D:INIT-ALLEOP( ) =   [initialize?( ){    stopPolling = false •→initialize = false   //Places orders with producers for new products.InterruptPort messaging has been ignored.    ∀(j)(0≦j<n){     •→D.g[j].rd:make(package, contents = φ)     •→ D.g[j]^(S)[t(D.g[j],0)]     m→(

P[j].f^(D)

[t(D.g[j],1)]||P[j]:BODY-ALLEOP( ))}}] (II.19)  D:BODY-ALLEOP( ) =   [

D:stopPolling{∀(j)(0≦j<m)    {D.f[j]:mR?(

D.f[j]^(D)

[(T(C[j].g,1) | (T(C[j].g,3)]){     •→ D:sortInto(D.f[j],D.sortedPortsList)}     •→ (for (j=0; j < sortedPortsList:size( );j++)){        sortedPortsList[j]:tip-ALLEOP( )}     •→ D:BODY-ALLEOP()}] (II.20)  D.f[j]:ALLEOP( ) =   [D.f[j]:mR?(

D.f[j]^(D)

[(T(C[j].g,1) | (T(C[j].g,3)]){           D.f[j]:tip-ALLEOP( )}] (II.21) D.f[j]:tip-ALLEOP( ) =   [(∃k(0≦k<n)D.g[k]:mR?(

D.g[k]^(D)

[t(P[k].f,1)]))*{    •→ D.g[k]:moveProduct(D.f[j])    •→D.g[k]^(S)[t(D.g[k],2)]    → (

P[k].f^(D)

[t(D.g[k],3)] || P[k]:BODY-ALLEOP( ))    •→ D.f[j]^(S)[t(D.f[j],0)]    →(

C[j].g^(D)

[t(D.f[j],1)] || C[j]:BODY-ALLEOP( ))}}] (II.22)  PC-Solution:ALLEOP( )=   □[∃(<partial-ordering-of-timing-functions>]   ∀(j)(0≦j<m)∀(k)(0≦k<n)      (|| C[j]:ALLEOP( )|| P[k]:ALLEOP( )||D:ALLEOP( ))] (II.23) Traces: Traces are presented in the ECT-Blocks inFigure 7.1 through 7.3 and the ECT- network is presented in Table 7.

APPENDIX III DP-SOLUTION: CIPs, TIPs, ALLEOPs and Traces

Btlr CIPs and Tips: Btlr stands for Butler. Here also we will ignoreinterruptPort polling, interrupt message processing and start/stopprocesses. void Btlr::CIP( ){INIT( ); BODY( )} (III.1) void Btlr::INIT(){  initialize?( ){stUpTbl( );  stopPolling=stopPending=initialize=false;   g:s( );//broadcasts signalto all philosophers in order to activate them.}   i:s( );//acknowledgesreceipt of interrupt signal that activated it.} (III.2) void Btlr::BODY(){  while(

stopPolling){ /*Polls its functionPorts btlr.f[j]and responds tomessages as specified in btlr.f[j]:TIP( )*/   for (int j = 0; j < 5;j++;){btlr.f[j]:TIP( );} /*terminates on receipt of interrupt signalfrom its environment at its interruptPort, btlr.i. Termination occursonly after serving all philosophers who are waiting for forks and afterall philosophers have also terminated, as specified in btlr.i:TIP(),described later below.*/   btlr.i:mR?( ){btlr.i:TIP( );}  prepareToTerminate( );} (III.3) Btlr.f[j:0...4]:TIP( ) =  [//listensto message from P[j].g and responds, if there is a message.  btlr.f[j]:mR?( ){ btlr:response(j); //this is a pthread defined inBtlr class. /*btlr.f[j].send is set in btlr:response(j) pthread. Ifbtlr.f[j].send = true then sends message if true, forwards message iffalse and does not respond if btlr.f[j].send = φ.*/  btlr.f[j]:send?(){f[j]:s( );} else {f[j]:f( );}] (III.4) Definition of btlr:response(j).void Btlr::response(int j) {//this pthread is executed only ifbtlr.f[j]:mR?( ) is true.  {selectOne{ /*If the readMemory at btlr.f[j]is empty, then it means philosopher P[j] is requesting forks. If forksare available, then packs forks into the container in the writeMemory ofbtlr.f[j] and sets btlr.f[j].send= true. This causes the message in thewriteMemory of btlr.f[j] to be sent out as defined in the body ofbtlr.f[j]:TIP( ) in (III.3). If forks are not available then setsbtlr.frk[j]:rsrvd=true and btlr.f[j].send = φ. In this case, no responseis sent. In this case P[j]will wait for forks. Forks will be sent whenthey eventually become available in an ensuing polling cycle. Since noresponse is sent btlr.f[j]:mR?( ) will evaluate to true in all ensuingpolling cycles, until forks are sent.*/   btlr.f[j].rd:empty?(){btlr:frksAvlbl?(j){btlr:packFrks(j);                 btlr.f[j].send=true;}             else {btlr.frk[j].rsrvd = true;                btlr.f[j].send = φ;} /*in the following, the readMemoryof btlr.f[j] is not empty. It will contain forks returned by P[j]. Btlrputs the forks back on table, and sets btlr.f[j].send = false. Thiscauses reply to be forwarded back to P[j].g by btlr.f[j]:tip( ) with anempty container in the readMemory.*/  

btlr.f[j].rd:empty?( ){btlr:putFrksOnTbl(j);          btlr.f[j].send=false;}} (III.5) btlr.i:TIP( ) =  [/*Thefollowing is executed only if there is an interrupt message at btlr.i.If btlr.pendingStop=false, then broadcasts signal to all philosophersthrough btlr.g. This asks the philosophers to end the game. Does notrespond to interrupt signal at btlr.i in this case, but instead setsbtlr.pendingStop = true, indicating that there is a pending stop for thegame, and proceeds immediately to service the functionPorts, btlr.f[j].Since no response has been sent, btlr.i:mR?( ) evaluates to true in thenext polling cycle of btlr, and at that point btlr.pendingStop will betrue. This causes the else-clause below to be executed. In this else-cause btlr waits to receive response from all philosophers, indicatingthat they have terminated. When this response is received, btlr setsstopPolling = true and sends back acknowledgement to the interruptsignal received through btlr.i. The game stops in the ensuing pollingcycle. */   btlr.i:mR?( ){selectOne{   

btlr.pendingStop { btlr.g:s( ); btlr.pendingStop =true;}   

btlr:allFrksOnTbl?( ){ btlr.pendingStop = false;           btlr.g:mR?()*{stopPolling=true;               i:s( );}}}}] (III.6)Notice, btlr services all philosophers with pending service requests inthe polling cycle in which the interrupt signal was sensed. Terminatesthe game only after all forks are on the table and after receivingacknowledgement from all philosophers that they have terminated.

The loop-invariant for the while-loop in btlr:BODY() is □(

∀(j)W(j)), where W[j] means philosopher P[j] is waiting for forks.∀(j)W(j) is the deadlock state. This state is never reached during thegame. The proof for this is given in Section 6.4. All actions andconditions characterized below are defined in the Btlr class.Implementations are not shown here for all actions. Theircharacterizations are given below.

DEFINITIONS: Characterization of Btlr actions and conditions. □[btlr.frk[j]:rsrvd?( )

 btlr.frk[j].rsrvd=true] (III.7)  □[btlr:frksAvlbl?(j)

  (btlr.frk[j]:onTbl & btlr.frk[j⊕₅1].onTbl &         

btlr.frk[j⊕₅1].rsrvd)] (III.8)  ∃(t₀ < t₁)[//characterization ofbtlr:packFrks(j).   {

btlr:frksAvlbl?(j)

(t₀)} [•→ btlr:packFrks(j)(t₀)]   {

btlr.f[j].wr:msg( ).contains=[btlr.frk[j], btlr.frk[j⊕₅1]] &    

btlr.frk[j].onTbl &

btlr.frk[j⊕₅1].onTbl &    

btlr.frk[j].rsrvd

(t₁)} (III.9)   //characterization of btlr::putFrksOnTbl(j).   {

btlr.f[j].rd:msg( ).contains =       [btlr.frk[j], btlr.frk[j⊕₅1]]

(t₀)}    [•→ btlr:putFrksOnTbl(j)(t₀)]   {

btlr.frk[j].onTbl & btlr.frk[j⊕₅1].onTbl &    

btlr.frk[j].rsrvd)(t₁)&     btlr.f[j].rd:msg( ).contains=φ

(t₁)} (III.10)   //characterization of btlr:rplnshFd( ).   {

btlr.foodContainer:empty?( )

(t₀)} [→ btlr:rplnshFd( )(t₀)]    {(btlr.foodContainer:full?( )(t₁)}(III.11)   //characterization of btlr:stUpTbl( ).   {true} [→btlr:stUpTbl( )(t₀)]    {

∀(j)(btlr:frksAvlbl(j))&      foodContainer:full?( )

(t₁)}] (III.12) Philosopher CIP and TIPs: void P::CIP( ){P:INIT( );P:BODY( );} (III.13) void P::INIT( ){ /*The writeMemory of P[j].gremains empty. An empty instance of package is installed in itsreadMemory.*/  initialize?( ){stopPolling = initialize = false;hasforks=φ;       i:s( ); g.rd:make(package, contains=φ}} (III.14) voidP::BODY( ){  while (

stopPolling){ //hunger begins when P stops thinking.   P:thinking( );P.g:TIP( );   //receipt of interrupt stops the game, else goes back tothinking.   P.i:mR?( ){P.i:s( ); stopPolling=true;}} prepareToTerminate( );} (III.15) P.g:TIP( ) = //Sends request forforks, when hunger begins and P.g is ready to send message.  [P:hungry?(){P.g:pR?( )*{P.g:s( );  /*After sending request for forks via its portP.g, waits for forks to arrive, picks them up when  they arrive, andbegins to eat. After eating packs forks and forwards them back tobtlr.*/   P.g:mR?( )*{P.g:pickUpFrks( ); P:eating( );      P.g:packFrks( ).f( );}} (III.16) DEFINITIONS: Philosopher P[j]Actions and Condition Characterizations, for 0≦j<5: ∃(t₀ < t₁ < t₁)[ //characterization of P[j].g:pickUpForks( ).  {

P[j].g:msg( ).contains=[frk[j],frk[j⊕₅1]]

(t₀)}   [•→ P[j].g:pickUpForks( )(t₀)]  {

P[j]:hasForks?( )

(t₁)} (III.17)  //Definition of P[j]:hasForks?( )  [P[j]:hasForks?( )

   (P[j].hasForks = [btlr.frk[j],btlr.frk[j⊕₅1]]) &          P[j].g.rd:msg( ).contents = φ)] (III.18)  //characterizationof P[j]:eating( )  {

P[j]:hasForks?( ) & P[j]:hungry?( )

(t₀)}[•→ P[j]:eating( )(t₀)]     {

P[j]:hungry? & P[j]:hasForks?( )

(t₁)} (III.19)  //characterization of P[j]:packFrks( )  {

P[j]:hasForks?( )

(t₀)} [•→ P[j]:packFrks( )(t₀)]   {

P[j].g:msg( ).contains=[frk[j],frk[j⊕₅1]] &    

P[j]:hasForks?( )

(t₁)} (III.20)  //characterization of P[j]:thinking( )  {

P[j]:hungry?( )

(t₀)}[

•→ P[j]:thinking( )

(t₁)]   {

P[j]:hungry?(t₁)} (III.21) ALLEOPs: In the following ‘|’ separatesalternates. Btlr ALLEOPs: btlr:ALLEOP( ) =   [btlr.init:ALLEOP( ) •→btlr.body:ALLEOP( )] (III.22) btlr.init:ALLEOP( ) = //E is theenvironment cell that starts the btlr.  [initialize?( ){stUpTbl( )//setsup the table        •→stopPolling=false        •→stopPending=false •→initialize=false       •→ g^(S)[t(btlr.g,0)] //starts all philosophers.      →(∀(j)(0≦j<5)(

P[j].i^(D)

[t(btlr.g,1)]         || →...→ P[j].init:ALLEOP( ))       •→btlr.i^(S)[T(btlr.i,0)]       → (

E.g^(D)

[T(btlr.i,1)]|| →...→ E.g:ALLEOP( ))}   •→ btlr.body:ALLEOP( )] (III.23)btlr.body:ALLEOP( ) =  [(

stopPolling?( ){∀(j)(0≦j<5)[btlr.f[j]:ALLEOP( )]             •→btlr.i:ALLEOP( )]             •→ btlr.body:ALLEOP( )} |   stopPolling?(){prepareToTerminate( )}] (III.24) btlr:f[j:0...4]:ALLEOP( ) = /*skipsto poll its next port if there is no signal, else does the following.This alternate is usually not specified. It is assumed.*/  [

btlr.f[j]:mR?( ){btlr:f[j⊕₅1]:ALLEOP( )} | /* message received at timet(P[j].f,1) is a request for forks. In this case, readMemory will beempty. Message received at time T(P[j].f,3) contains forks returned byP[j] in the readMemory. Btlr:response(j) processes these messages asdescribed in the next ALLEOP and sets f[j]:send?( ) to true, false orφ*/  btlr.f[j]:mR?(

btlr.f[j]^(D)

[T(P[j].f,1)| t(P[j].f,3)]){    •→ btlr:responseALLEOP(j)    •→(f[j]:send?( ){f[j]^(S)[T(btlr.f[j], 0)]           → (

P[j].g^(D)

[T(btlr.f[j],1)]             ||→...→ P[j].g:ALLEOP( ))} |     

f[j]:send?( ){f[j]^(F)[t(btlr.f[j],0)]            → (

P[j].g^(D)

[btlr.f[j],1)]             ||→...→ P[j].g:ALLEOP( ))} |      true{ }/*nomessage is sent in this case*/)}}    •→ btlr:f[j⊕₅1]:ALLEOP( )/*proceeds to poll its next port*/.] (III.25) btlr:responseALLEOP(j:0...4)= /* If message from P[j].g is empty then P[j] is requesting forks. Inthis case, if forks are available packs forks into container inwriteMemory of btlr.f[j and sets btlr.f[j].send =true in order to sendit off to P[j].g. Else puts the left fork, btlr.frk[j], on reserve andsets btlr.f[j]send =φ in order to not send any message back to P[j].g.It may be noted, in the next polling cycle of btlr, btlr.f[j]:mR?( )will still evaluate to true and the same response activities will berepeated again. This cycle of activities continues until forks becomeavailable and are sent to P[j].g. If message is not empty, then P[j].gis returning forks. In this case puts forks back on table and setsbtlr.f[j].send=false in order to forward the empty container in thereadMemory back to P[j].g. */  btlr.f[j].rd:empty?( ){   (btlr:frksAvlbl?(j){btlr:packFrks(j)             •→ btlr.f[j].send=true;} |    

btlr:frksAvlbl?(j){btlr.frk[j].rsrvd = true             •→btlr.f[j].respond = φ;})} |    

btlr.f[j].rd:empty?( ){btlr:putFrksOnTbl(j)            •→btlr.f[j].send=false;})))] (III.26) btlr.i:ALLEOP( ) = /*Eis the environment cell that started the butler. E.g sends the interruptsignal to btlr.i. ALLEOP for E.g is not shown here. On sensing theinterrupt signal btlr does the following: if btlr.pendingStop is falsethen it is now set to true and a signal is broadcast from port btlr.g,to interruptPorts of all philosophers advising them that dinner isover.*/   [btlr.i:mR?(

btlr.i^(D)

[t(E.g,3)]){      (

btlr:pendingStop?( ){        btlr.pendingStop=true         •→g^(S)[T(btlr.g,2)]          (∀(j)((0≦j<5)[

→ P[j].i^(D)

[T(btlr.g,3)]            || →...→ P[j].i:ALLEOP( ))]} | /* ifbtlr.pendingStop is true and all forks are on the table then waits forresponse from all the philosophers. On receipt of the responseacknowledges receipt of interrupt signal from E.g and then prepares toterminate. Terminates in the ensuing polling cycle. btlr:allFrksOnTbl?() signifies that all philosophers have finished eating and returned theforks. */      btlr: pendingStop?( ) & btlr:allFrksOnTbl?( )){          btlr.g:mR( )*{•→ i^(S)[t(btlr.i,2)]           → (

E.g^(D)

[t(btlr.i,3)] || →...→ E.g:ALLEOP( ))}           •→ btlr.stopPolling =true           •→ btlr.pendingStop = false})}] (III.27)As we have already mentioned, btlr terminates operations only after allwaiting philosophers have been serviced and all philosophers havestopped eating and returned the forks.

Philosopher ALLEOPs: P[j:0...4]:ALLEOP( ) =     [P[j].init:ALLEOP( ) •→P[j].body:ALLEOP( )] (III.28) P[j:0...4].init:ALLEOP( ) = [P[j]:initialize?( ){P[j].stopPolling = false        •→ P[j].initialize= false        •→ P[j].hasForks = φ        •→ P[j].i^(S)[t(P[j].i,0)]       → (

btlr.g^(D)

[P[j].i,1)]          || →...→ btlr.body:ALLEOP( ))}        •→P[j].g.rd:make(package, contains=φ)}   •→ P[j].body:ALLEOP( )] (III.29)P[j:0...4].body:ALLEOP( ) =  [(

P[j]:stopPolling?( ){ P[j].g:ALLEOP( ) •→ P[j].i:ALLEOP( )}           •→P[j].body:ALLEOP( )} |   P[j]:stopPolling?( ){prepareToTerminate( )})](III.30) P[j:0...4].g:ALLEOP( ) =  [P[j]:thinking( ) •→   P[j]:hungry?(){    P[j].g:pR?( )*{     P[j]:g^(S)[T(P[j].g,0)]      → (

btlr.f[j]^(D)

[t(P[j].g,1)]||→...→ btlr.f[j]:ALLEOP( ))    •→ P[j].g:mR?()*{P[j].g:pickUpForks( ) •→ P[j]:eating( ) /*packs forks into thecontainer in the readMemory of P[j].g and forwards it to btlr.f[j aftereating.*/    •→ P[j].g:packFrks( )    •→ P[j].g^(F)[t(P[j].g,2)]    → (

btlr.f[j]^(D)

[t(P[j].g,3)]        ||→...→ btlr.f[j]:ALLEOP( ))}}] (III.31)P[j].i:ALLEOP( ) = /*Notice in (I.30), P[j] polls its interruptPort onlyafter he/she has finished eating and sent back the forks.*/  [P[j].i:mR?(

P[j].i^(D)

[t(btlr.g,3)]){i^(S)[t(P[j].i,2)]     → (btlr.g^(D)[t(P[j].i,3)] ||btlr.body:ALLEOP( ))     •→ stopPolling=true }] (III.32)A waiting philosopher responds to the termination signal only afterhe/she has eaten. Thus, before game ends every philosopher would havebeen satiated.

Polling Cycles: btlr:Polling( ) =  [btlr.f[0]:mR?( ) → btlr.f[1]:mR?( )→ btlr.f[2]:mR?( )  → btlr.f[3]:mR?( )→ btlr.f[4]:mR?( ) → btlr.i:mR?( )  → btlr:Polling( )] (III.33) P[j:0...4]:Polling( ) =  [P[j].g:pR( )* →P[j].i:mR?( )→ P[j]:Polling( )] (III.34)

Distinguished Predicates & Initial States:

The set of distinguished predicates is used to specify initial statesbefore evaluation of ETC-network begins. Generally speaking,distinguished predicates include conditions that determine choices to bemade at choice points in TIPs. Thus, any non-standard guards and statusof messages in virtualMemories and states defined for cells will beincluded in this set. For example, in this example, the guard and statusof message in a virtualMemory are included in this set, if a servicerequest at a functionPort is not responded to before execution of thenext TIP begins. Rule for symbolic evaluation of ECTs is: if a predicatedetermining the choice at a choice point is not specified in the initialstate, or among predicates used earlier in the ECT-evaluation, then allcausal chains emanating from that choice point should be included aspossible alternates in the symbolic evaluation.

For DP-solution, the distinguished predicate set includes the followingconditions:

btlr:frksAvlbl?(j), E[j], T[j] and W[j], btlr.f[j]:mR?( ) andbtlr.f[j].rd:empty?( ),for 0≦j<5. (III.35)The states of philosophers, T[j] (thinking P[j]) W[j] (waiting P[j]) andE[j] (eating P[j]) are defined in Section 6.4. Axioms of the game andits initial conditions are also defined there. The proofs presented InSection 6.4 require only P[j].g:trace(p[j].g.t₀) andbtlr.f[j]:trace(bf[j].t₀). ECT-networks derived from traces are shown inTables 8, 8.1 and 9, 9.1 and 9.2. For convenience and clarity we havesplit up the network into easy to read blocks that follow one another,or activate each other through parallel activations. Reader may noticethat in each ECT-block the pre and post conditions defined for actionsare included in the block. Information needed for proofs are picked upfrom these two tables.

This completes the implementation and definition of DP-Solution.

APPENDIX IV Brief Descriptions of Figures and Tables 1. Figures.

1. Simple Pathway: Used to exchange signals between two cells, LEGEND inTable 1.

2. Point-to-Point Das Pathway with virtualMemory: Used to exchangemessages between two cells, LEGEND in Table 2.

3. A simple Point-to-Group pathway: Used to broadcast signal from onecell to a group of cells, LEGEND in Table 3.

4. Point-to-Group Das Pathway with virtualMemory: Used to broadcastmessages from one cell to a group of cells, LEGEND in Table 4.

5. TICC™-Network for Bill-Ben game: Used to illustrate synchronizationand coordination.

6 A. ALLEOPs-Network for Bill-Ben Game. Used as a model of Bill-Benimplementation.

-   -   B. Causalnet for a single run of Bill-Ben game: Used to        dynamically monitor the game.    -   C. Causalnet for multiple iterations of Bill-Ben game.

7. TICC™-Network for Talking-Itching Problem Solution: An exampleshowing decomposition of a compound cell and encapsulation, parallelismand coordination.

8. Moving apart dependent ports in a cell to two different cells.

9. Comparing Conventional and TICC™ Parallel Processing SystemArchitectures.

10. TICC™-Network for Ornamental Garden Solution (OG-Solution).

11. Schematic Diagram of a VirtualMemory.

12. TICC™-Network for Producer/Consumer problem Solution (PC-Solution).

13. TICC™-Network for Dining Philosopher problem solution (DP-Solution).

14. Branching tree of Configurations in a Polling Cycle of Butler cellin DP-Solution.

15. Illustrating State Transitions in Butler cell in successive PollingCycles.

16. Illustrating Ad Hoc Coordination in TICC™-Ppde.

17. Illustrating Ad Hoc Synchronization in TICC™-Ppde.

18. A growing TICC™-Network with Non-Finite State ALLEOPs.

19. Group-to-Group sm-pathway and SMS infrastructure.

20, Causalnet Fragment of message sending cells installed by SMS inGroup-to-Group Communications.

21. Causalnet Fragment of message receiving cells installed by SMS inGroup-to-Group Communications.

22. Combined sending/receiving causal net fragment in Group-to-Groupcommunications.

23. One-way Ring Sm-Pathway.

24. A Schematic Diagram of a dm-pathway from a generalPort group in oneSMP (Shared memory Multi-Processor) to functionPort groups in other SMPsin a super-computing grid, interconnected by dm-pathways in a TICCNET™.

2. Tables

1. LEGEND for FIG. 1: TIPs, pathway states, protocols andCCP-characterizations.

2. LEGEND for FIG. 2: TIPs, pathway states, protocols andCCP-characterizations.

3. LEGEND for FIG. 3: TIPs, pathway states, protocols andCCP-characterizations.

4. LEGEND for FIG. 4: TIPs, pathway states, protocols andCCP-characterizations.

5. ECT-Network for Entrance Gate of OG-Solution.

-   -   5.1. Events in Block(5a) of Table 5.    -   5.2. Events in Blocks(5b) through Block(5d) of Table 5    -   5.3. Events in Counter during Entrance, Block(e) through        Block(5g).

6. ECT-Network for Exit Gate of OG-Solution.

-   -   6.1. Events in Exit Gate, Block(6a) through Block(6c) in Table        6.    -   6.2. Events in Counter during Exit, Block(6d) of Table 6.

7. ECT-Network for Philosopher P[j] in PC-Solution.

-   -   7.1. Events in Blocks (7a) and (7b) of Table 7, Consumer Events.    -   7.2. Events in Blocks (7c) and (7d) of Table 7, Distributor        Events.    -   7.3. Events in Block(7e) of Table 7, Producer Events.

8. ECT-Network for Philosopher P[j] in DP-Solution.

-   -   8.1. Events in Blocks(8b) through (8d), Philosopher Events.

9. ECT-Network for Butler in PC-Solution.

-   -   9.1. Events in Blocks (9i) ad (9j) in Table 9, Butler Events    -   9.2. Events in Block (9m) in Table 9, Butler Events continued.

TABLE 1 LEGEND FOR FIG 1. TIPs, Protocols and Logical Characterizationsof CCPs appearing in the protocols, for the components in FIG 1.TIPS: 1) C.g:pR?( ){C.g:x( ).s( );} 2) D.f:mR?( ){D.f:r( ).s( );}COMMUNICATION PROTOCOLS: 1) C.g:s( ) = [C:c → C.g:s → D.f] 2) D.f:s( ) =[D:c → D.f:s → C.g] STATE CHANGES: [S,R] → [R,S] → [S,R] LOGICALCHARACTERIZATIONS OF CCPs:  1) {C.g.state=S}[C:c → C.g]{C.g.input=c}  2){C.g.state=S & C.g.input=c & C.f.state=R}  [C.g:s → C.f]{C.g.state=R &C.f.input=s}  3) {C.f.input=s}[C.f:mR?( )]{true & C.f.state=S}  4){C.f.input≠s}[C.f:mR?( )]{false}  5) {D.f.state=S}{D:c →D.f}{D.f.input=c}  6) {C.f.state=S & f.input=c & C.g.state=R}    [C.f:s→ C.g]{D.f.state=R & C.g.input=s}  7) {C.g.input=s

 C.g.state=S}[C.g:pR?( )]     {true & C.g.state=S & C.g:input=φ}  8){C.g.input=s & C.g.state=S}[C.g:pR?( )]     {true & C.g.state=S &C.g.input=φ}  9) {C.g.input≠s & C.g.state=S}[C.g:pR?( )]{false} 10){C.g.input≠s}[C.g:mR?( )]{false}

TABLE 2 LEGEND FOR FIG 2. TIPs, Protocols and Logical Characterizationsof CCPs appearing in the protocols, for the components in FIG 2.TIPs: 1. C.g:pR?( ){g:x( ).s( );} 2. D.f:mR?( ){f:r( ).s( );}COMMUNICATION PROTOCOLS: 1. C.g:s( )= [C:c → C.g:c → a0:s → a1:s → D.f;]2. D.f:s( )= [D:c → D.f:c → a1:s → a0:s → C.g;] STATE CHANGES: [S, S, R,R] → [R, R, S, S] → [S, S, R, R] LOGICAL CHARACTERIZATIONS OF CCPs:  1.{C.g.state=S}[C:c → C.g]{C.g.input=c}  2. {C.g.state= S & C.g.input=c &a0.state= S}[C.g:c → a0]     {C.g.state= R & a0.input=c}  3. {a1.input=c& a1.state= R & a0.state= S}[a0:s → a1]     {a0.state= R & a1.input=s} 4. {a1.input=s & a1.state= R & D.f.state= R}[a1:s → D.f]     {a1.state=S & D.f.input=s}  5. {D.f.input=s}[D.f:mR?( )]{true & D.f.state= S]  6.{D.f.input≠s}[D.f:mR?( )]{false}  7. {D.f.state= S}[D:c →D.f]{D.f.input=c}  8. {D.f.state= S & D.f.input=c & a1.state= S}[D.f:c →a1]     {D.f.state= R & a1.input=c}  9. {a1.input=c & a0.state= R &a1.state= S}[a1:s → D.f]     {a1.state= R & a0.input=s} 10. {a0.input=s& a0.state= R & C.g.state= R}[a0:s → C.g]     {a0.state= S &C.g.input=s} 11. {C.g.input=s

 C.g.state = S}[C.g:pR?( )]      {true & C.g.state= S & C.g.input=φ} 12.{C.g.input≠s & C.g.state ≠ S}[C.g:pR?( )]{false} 13.{C.g.input=s}[C.g:mR?( )]{true & C.g.state= S & C.g.input=φ} 14.{C.g.input≠s}[C.g:mR?( )]{false}

TABLE 3 LEGEND FOR FIG 3. TIPS: 1. C.g:pR?( ){C.g:x( ).s( );} 2.D₁.f:mR?( ){D₁.f:r( ).s( );} 3. D₂.f:mR?( ){D₂.f:r( ).s( );}PROTOCOLS: 1. C.g:s( ) = [C.g:c → a0:s → [D₁.f, D₂.f]] 2. (D₁.f:s( ) ||D₂.f:s( )) =   [D₁.f:c₁ || D₂.f:c₂] → a0:AP[c₁,c₂]*:s → C.g]

TABLE 4 LEGEND FOR FIG 4. TIPS: 1. C.g:pR?( ){C.g:x( ).s;} 2. D₁.f:mR?(){D₁.f:r( ).s( );} 3. D₂.f:mR?( ){D₂.f:r( ).s( );} PROTOCOLS: 1. C.g:s() = [C.g:c → a0:s → a1:s → [D₁.f, D₂.f]] 2. [D₁.f:s( ) || D₂.f:s( )] =  [D₁.f:c₁ || D₂.f:c₂] → a1:AP[c₁,c₂]*:s →              a0:s → C.g]

TABLE 5 STRUCTURE OF ECT-NETWORK FOR THE ENTRANCE GATE

TABLE 5.1 ENTRANCE SENSOR ECT BLOCK(5a) SENSOR ECTSe[j].f:port-ECT(se[j].t₀) Event Time Nos. Events Points 1.[<Se[j].f^(D)>] se[j].t₀ 2. <Se[j]:mR?(<Se[j].f^(D)>)*> //from sensorse[j].t₁ 3. Se[j]:personEntering se[j].t₁ 4. [→ Se[j].g^(S)] se[j].t₁ 5.[<→ Et[j].f_(t) ^(D)>] //to(5b,2) se[j].t₂ 6. <Se[j].g^(D)> (e[j]ft.t₃ |e[j]ft.t₅) = se[j].t₃ 7. <Se[j].g:mR?(<Se[j].g^(D)>)*>//from((5c.6)|(5d,9)) se[j].t₃

TABLE 5.2 COUNTER ECT FOR ENTRANCE

TABLE 5.3 COUNTER ECT FOR ENTRANCE

TABLE 6 EXIT GATE ECT-NETWORK

TABLE 6.1 EXIT SENSOR & EXIT GATE ECTs.

TABLE 6.2 COUNTER ECT FOR EXIT BLOCK(6d) COUNTER ECT.C.f[j+2]:port-ECT(cf[j+2].t₀) Event Nos. Events Time Points 1.[<C.f[j+2].g^(D)> x[j]g.t₁ = cf[j+2].t₀ 2.<C.f[j+2].g:mR?(<C.f[j+2]^(D)>)*> //from(6b,4) cf[j+2].t₁ 3. [→counter--] cf[j+2].t₂ 4. (counter.count < max) cf[j+2].t₃ 5. [→C.f[j+2]^(S)] cf[j+2].t₃ 6. [<→ Xt[j].g^(D)>] //to(6c,2) x[j]ft.t₂

TABLE 7 PC-Solution ECT-Network.

TABLE 7.1 CONSUMER[j] ECT, j = 0, 1, . . . , m

TABLE 7.2 DISTRIBUTOR ECT Event Nos. Events Time Points BLOCK(7c)DISTRIBUTOR INIT, k = 0, 1, . . . , n D.init:ECT(dg[k]I.t₀) 1. [→D.g[k].g:make(package)] dg[k]I.t₀ 2. D.g[k]:msg( ).contents=φ dg[k]I.t₁4. [→ D.g[k]^(S)] dg[k]I.t₁ 5. [<→ P[j].f^(D)>] //to(7e,2) dg[k]I.t₂BLOCK(7d) DISTRIBUTOR D.f[j]:port-ECT(df[j].t₀) 1. [<D.f[j]^(D)>](c[j]I.t₃ | c[j]g.t₄) = df[j].t₀ 2. <D.f[j]:mR?(<D.f[j]^(D)>)>//from((7a,4)|(7b,8)) df[j].t₁ 3. ∃(i)[<→ D.g[i]^(D)>] //from (7e,7)dg[k].t₃ 4. ∃(k)((0≦k<n)(D.g[k]:mR?( ))* dg[k]t.t₀ 5. ∃(Productx)(D.g[k]:msg( ).contents=x) dg[k]t.t₀ 6. ∃(j)[→D.g[k]:moveProduct(f[j])] dg[k]t.t₁ 7. D.g[k]:msg( ).contents=φ)dg[k]t.t₂ 8. (D.f[j]:msg( ).contents=x) dg[k]t.t₂ 9. [→ D.g[k]^(S)]dg[k]t.t₂ 10. [<→ P[k].f^(D)>] //to (7e,2) dg[k]t.t₃ 11. [→ D.f[j]^(S)]dg[k]t.t₃ 12. [<→ C[j].g^(D)>] //to (7b,2) dg[k]t.t₄

TABLE 7.3 PRODUCER[k] ECT, k = 0, 1, . . . , n BLOCK(7e) PRODUCER[i], i= 0, 1, . . . , n P[k].f:port-ECT(p[k]f.t₀) Event Nos. Events TimePoints 1. [<P[i].f^(D)>] (dg[i]I.t₂ | dg[i]t.t₃) = p[i]f.t₀ 2.<P[i].f:mR?(<P[i].f^(D)>)> //from((7c,4)|(7d,10)) p[i]f.t₁ 4. ∃(Productx)(x=P[i]:produceProduct( )) p[i]f.t₂ 5. P[i].f.wr:msg( ).contents=x)p[i]f.t₃ 6. [→ P[i].f^(S)] p[i]f.t₄ 7. [<→ D.g[i]^(D)>] //to (7d,3)dg[i]t.t₄

TABLE 8 PHILOSOPHER ECT-NETWORK

TABLE 8.1 PHILOSOPHER[j] ECTs.

TABLE 9 BUTLER ECT-NETWORK

TABLE 9.1 BUTLER ECTS Event Nos. Events Time Points BLOCK (9i) PACK ANDSEND FORKS 0 ≦ j < 5 Btlr.f[j].pack&SendForks:ECT(bf[j].t₃) 1. [<→btlr:packForks( )>] bf[j].t₃ 2. Btlr.f[j].wr.msg( ).contains bf[j].t₃[btlr.frk[j], btlr.frk[j⊕₅1]] 3.

btlr.frk[j].rsrvd bf[j].t₃ 4. btlr.frk[j].onTbl bf[j].t₃ 5.btlr.frk[j⊕₅1].onTbl bf[j].t₃ 6. [→ btlr.f[j]^(S)] bf[j].t₃ 7. [<→P[j].g^(D)>] //to(8b,1) bf[j].t₄ 8.

btlr:frksAvlbl?(j) bf[j].t₄ 9.

btlr:frkAvlbl?(j⊕₅1) bf[j].t₄ 10.

btlr:frkAvlbl?(j⊕₅4) bf[j].t₄ BLOCK(9j) PUT FORKS BACK 0 ≦ j < 5Btlr.f[j].putForksBack:ECT(bf[j].t₃) 1. btlr.f[j].rd:msg( ).containsbf[j].t₃ [btlr.frk[j], btlr.frk[j⊕₅1]] 2. [<→ btlr:packForks( )>]bf[j].t₅ 3.

btlr.frk[j].rsrvd bf[j].t₅ 4. btlr.frk[j].onTbl bf[j].t₅ 5.btlr.frk[j⊕₅1].onTbl bf[j].t₅ 6. btlr.f[j].rd:msg( ).contains=φ bf[j].t₅6. [→ btlr.f[j]^(F)] bf[j].t₅ 7. [<→ P[j].g^(D)>] //to(8d,7) bf[j].t₆

TABLE 9.2 BUTLER ECTS (CONTD.) BLOCK(9m) PUT FORKS ON RESERVEBtlr:putForkOnReserve(j):ECT(bf[j].t₃) Event Nos. Events Time Points 1.[<→ btlr.frk[j].rsvd=true>] & & W[j] bf[j].t₇ 2.

btlr:frkAvlbl?(j) bf[j].t₇ 3.

btlr:frkAvlbl?(j⊕₅4) bf[j].t₇ 4. btlr.frk[j].onTbl bf[j].t₇ 5.btlr.frk[j⊕₅1].onTbl bf[j].t₇ 6.<btlr.f[j]:mR?(<btlr.f[j]^(D)>(pjf.t₁))> bf[j].t₈ 7.btlr.f[j].rd:empty?( ) bf[j].t₈

PREFACE TO CLAIMS

The terms, name, attribute, data, method, condition, abstract,refinement, run, action event and communication event, used in therecitation of claims are defined in this

Preface:

-   (i) name, is any finite string in a given alphabet of symbols,-   (ii) data is any finite string of binary bits 0 and 1, usually used    to represent values,-   (iii) attribute is any name used to define a property of an object    instance, x, x.attribute being used to refer to the value of that    attribute for object x, x.attribute being defined in the class X of    object instance x.-   (iv) method has the format x:name(<arguments>), <arguments>being    optional; each method is a computer program, the computer program    for method x:name(<arguments>) being defined in the class X of the    object instance x. A method is abstract if no computer program has    been defined for it.-   (v) condition has the form x:name?() with no arguments; each    condition is a computer program, the computer program for the    condition x:name?() being defined in the class X of the object    instance x. Evaluation of a condition will return truth value true    or false, or truth value true, false or φ (empty). A condition is    abstract if no computer program has been defined for it.-   (vi) abstract: A software component is abstract if it contains    abstract methods and/or conditions.-   (vii) refinement: Refinements consist of three processes: (i)    decomposition of a compound cell into a sub-network of cells and    communication pathways, the sub-network being encapsulated inside    the compound cell (see example in FIG. 7), (ii) defining message    subclasses and (iii) defining computer programs for abstract methods    and conditions in the software components of cells and messages. An    implementation is fully refined if all compound cells have been    fully refined, all message subclasses have been defined and computer    programs have been defined for all methods and conditions in every    software component of the implementation.-   (viii) run: execution of fully refined parallel computer programs    for an application, A, is called a run of A, each parallel computer    program in A being executed by a distinct dedicated CPU (ComPuting    Unit), the parallel computer programs in A interacting with each    other through message exchanges, while A is running, this being the    only mode of interaction among the parallel computer programs in A.-   (ix) action event: an action event has the form (name, t), action    event being caused by the execution of a statement in a programming    language, or execution of a method or condition, name being the name    of the event caused by that execution, and t being the time of    occurrence of that event.-   (x) Communication event: a communication event has the form    (name^(S), t) or (name^(D), t) or (name^(F), t) (‘S’ for ‘Send’, ‘D’    for ‘Deliver’ and ‘F’ for ‘Forward’) communication event occurrence    being caused by the execution of a communication statement in    TICC™-Ppde programming language, name being the name of a port    attached to a cell that sends/receives or forwards messages    exchanged in communications, t being the time of occurrence of that    communication event.

1. TICC™-Ppde, the integrated Parallel program development and executionplatform, based on a modified version of TICC™, Technology forIntegrated Computation and Communication, U.S. Pat. No. 7,210,145 B2,inventor Chitoor V. Srinivasan, teaches following methods: methods(1.1)for implementing parallel computer programs for applications, A:TICC™-Ppde providing methods for implementing parallel computer programsfor an application A, starting from abstract specifications ofinteractions among abstract software computing units called cells, theset of cells together with all interaction specifications associatedwith them being the abstract design for parallel programs of applicationA, called A:DESIGN(), progressively refining cells and interactions inA:DESIGN() to their final fully refined implementation, defining designrequirements at the time of design in a formal language called CausalTemporal Language, herein after referred to by CTL, parallel computerprograms in application A at any stage of refinement being calledA:implementation(), design requirements being updated by designers atevery stage of refinement, design requirements at every stage ofrefinement being called A:requirements(), the set of all cells inA:implementation() being called A:cells(), each cell in A:cells()interacting with other cells in A:cells() only through message exchangesvia already established communication pathways, each cell running in itsown dedicated hardware CPU (hardware ComPuting Unit), this CPU not beingshared with any other cell in A:cells() ; methods(1.2) for messageexchanges unique to TICC™-Ppde: the difference between TICC™ parallelprogramming paradigm and all other parallel programming paradigms beingin the way TICC™-Ppde manages point-to-point and group-to-groupcommunications among cells in A:cells(), enabling each cell itself todeliver messages it computes to their intended destination cells,immediately after a message becomes ready to be sent, in parallel withall other such message exchanges occurring simultaneously inA:implementation(), allowing almost instantaneous guaranteedasynchronous synchronized message deliveries to intended destinationswith precisely predictable latencies of the order of at most a fewhundreds of nanoseconds, assuming 2-gigahertz CPUs, with no need formessage scheduling or synchronization sessions; methods(1.3) forformally verifying A:implementation(): at each stage of refinement,including the A:DESIGN() stage, TICC™-Ppde automatically generating anevent based model of computations up to that stage of refinement, thismodel being called ALLEOPs (ALLowed Event Occurrence Patterns), ALLEOPsfor A:DESIGN() being called A:designALLEOPS() and ALLEOPs forA:implementation() at any stage of refinement being called A:ALLEOPS(),TICC™-Ppde using A:designALLEOPS() and A:ALLEOPS() to validate designsand implementations at any stage of refinement through formalverification of CTL statements in A:requirements(), TICC™-Ppde usingA:designALLEOPS() and A:ALLEOPS() to find validity proofs forCTL-assertions in A:requirements(), interacting with users during searchfor proofs, users providing additional CTL-assertions to guide proofsearch where necessary; methods(1.4), for running fully refinedA:implementation() with automatic self-monitoring using TICC™-Ppde SMS(Self-Monitoring System): A:ALLEOPS() also being used by TICC™-Ppde forautomatic dynamic monitoring of a fully refined A:implementation() forcorrect operation while A is running, in parallel with application A,throughout its life time, with little or no interference with timings ofcomputational events occurring in application A, identifying andreporting errors, pending errors, and occurrences of a priori definedalert event patterns, this dynamic monitoring being done automaticallyby SMS (Self-Monitoring System) built into the communication mechanismsof TICC™-Ppde; methods(1.5), for running arbitrarily scalableA:implementation() in massively parallel multi-computer hardwaresystems: running scalable A:implementation() at efficiencies in therange of 80% to 100% in arbitrarily large numbers of CPUs (hardwareComPuting Units), such CPUs being, (i) CPUs in any SMP (Shared-memoryMultiProcessor) with 32 or more CPUs, the CPUs in SMP communicating witheach other using software shared memory communication pathways(sm-pathways) of TICC™-Ppde installed in A:implementation(), or (ii)CPUs in any DMP (Distributed-Memory multiprocessor) whose computingnodes are SMPs, each with 32 or more CPUs, the SMPs in the DMPcommunicating with each other using hardware distributed-memorycommunication pathways (hereinafter referred to as dm-pathways) ofTICC™-Ppde, dm-pathways being embedded in a local area net, calledTICCNET™, or (iii) CPUs in any multi-core chip implemented as an SMPcontaining 32 or more CPUs, all CPUs in the chip sharing a common memoryand communicating with each other through software sm-pathways(shared-memory pathways) installed in A:implementation(), or (iv)multi-core chips containing 256 or more CPUs, all sharing a collectionof independent Shared Memory Modules, hereinafter referred to as SMMs,each SMM allowing anywhere from 2 to 16 CPUs to share the SMMsimultaneously, sharing of SMMs by CPUs in the chip being organized in amanner that exploits the virtualMemory organization of TICC™-Ppde, thisorganization providing increased execution efficiencies and dramaticallyimproving data and system security, while at the same time eliminatingthe need to use TICCNET™ for communications among independent CPUs andusing independent SMMs, or (v) CPUs in an SCG (SuperComputing Grid),each computing node of SCG being either an SMP or a DMP integrated in asingle chip, SCG containing an arbitrary but fixed number of such SMPsand DMPs, SMPs and DMPs in SCG being interconnected by dm-pathways in alocal area TICCNET™; methods(1.6), for building scalableCPPSS:implementation() for real-time Cyber-Physical Parallel SoftwareSystems with built-in SMS (Self-Monitoring System) using same methods ofimplementation through abstract design, successive refinements,requirements specifications and validation through formal verificationat each stage of refinement, and automatic run-time self-monitoringusing SMS; methods(1.7), for building scalable AHS:implementation() forAsynchronous Hardware Systems or embedded systems with built-in SMS(Self-Monitoring System), using same methods of implementation throughabstract design, successive refinements, validation through formalverification at each stage of refinement, and automatic run-timeself-monitoring using SMS;
 2. Methods as recited in claim 1 furtherincluding following methods for specifying A:DESIGN() and buildingA:TICC™-network: methods(2.1), for specifying A:DESIGN(): A:DESIGN()being an abstract specification of the control-structure of parallelcomputations in A:implementation(), A:DESIGN() specifying implicitly allmessage synchronization and coordination in application A and causalchains of action and communication events that may occur in computationsperformed by A, A:DESIGN() having five abstract software components, (i)A:cells(), (ii) A:pathways(), (iii) A:TICC™-network(), (iv) A:TIPS() and(v) A:CIPS(), these components being described below: (i)A:TICC™-network() (hereinafter called the network) being a graph withnodes and branches, branches interconnecting the nodes, nodes of thisgraph being abstract cells in A:implementation() and branches of thisgraph being abstract communication-Pathways (hereinafter calledpathways) that interconnect software communication ports (hereinaftercalled ports) attached to cells in the network, the set of all cells inthe network being called A:cells(), the set of all ports in the networkbeing called A:ports(), the set of all pathways in the network beingcalled A:pathways(), each cell in A:cells() being intended to run inparallel with all other cells in A:cells(), each in its own assignedhardware CPU (ComPuting Unit), each cell in the network intended toperform computations by exchanging messages with other cells in thenetwork through ports attached to the cell via pathways connected tothose ports, there being no limit to the number of ports a cell may have(in practice the number of ports attached to a cell being limited to 16)but no port being attached to more than one cell, some cells in thenetwork receiving inputs from the environment that is external toapplication A, this environment itself being represented in the networkby an environment cell, (ii) A:pathways: pathways interconnectingsoftware ports attached to different cells in the network, ports beingused by cells to send and receive messages via pathways connected tothem, each port being attached to only one unique cell, called theparent-cell of the port, thereby preventing contention for ports fromcells in A:cells(), each port being connected to exactly one pathway,thereby preventing message interference during parallel messagedeliveries, many ports being connected to the same pathway enablinggroup-to-group communications, each port connected to a pathway beingattached to a distinct cell, a port-group being a group of one or moreports connected to the same pathway, no two ports attached to the samecell being in a port-group, no two distinct port-groups containing portsin common, pathway enabling group-to-group communication amongport-groups connected to a pathway, it being possible for a port-groupto send message to itself via a self-loop pathway connected to thatport-group, in all such group-to-group message exchanges the messagesending port-group always sending a coordinated joint message fromparent-cells of ports in that port-group to the message receivingport-group, such joint messages from message sending port-group beingalways coordinated and simultaneously delivered in parallel to themessage receiving port-group, such coordination and synchronization ofmessage transfers in group-to-group communications being automaticallydone by agents embedded in pathways, (iii) A:TIPS(): interactions amongcells being specified by abstract Thread Interaction Primitives, calledTIPs, each TIP providing an abstract specification of how a cell sensesmessage delivered to any one of its ports, how it processes deliveredmessage and responds to it, it being possible for a TIP to spawncomputations over other cells in A:TICC™-network(), gathering responsesfrom those other cells before computing and sending back the responsemessage, each port of each cell in A:cells() having an abstract TIPdefined for it, only ten different kinds of TIPs being necessary toimplement any parallel program, five kinds of TIPs being calledsynchronous TIPs and other five kinds asynchronous TIPs, sensing of amessage by a cell at any one of its ports always causing the cell toprocess and respond to that message without fail by executing the fullyrefined TIP defined at that port, spreading computations over severalother cells in A:TICC™-network() if necessary, gathering responses fromcells in A:TICC™-network() in order to compute the response message,every message delivered to every port of a cell being sensed by the cellwithout fail, every service request message received by a cell at anyone of its ports being responded to by the cell without fail,computations performed by cells being thus driven by message receipts,the set of all abstract TIPs defined in A:DESIGN() being calledA:TIPS(), (iv) computations being performed by each cell C by cyclicallyexecuting TIPs defined at ports attached to C, TIPs defined at ports ofC being called C:TIPS(), cyclic computations performed by each cellbeing specified, again in an abstract form, by Cell InteractionProtocols, called CIPs, the CIP defined for a cell C being calledC:CIP(), and the set of all CIPs defined for cells in A:DESIGN() beingcalled A:CIPS(), all specifications up to this point being abstract, theabstract specifications merely identifying place-holders for methods andconditions used in A:DESIGN(), A:DESIGN() also implicitly specifyingcoordination and synchronization of message exchanges and computationsperformed by cells in A:cells() and causal chains of action events andcommunication events that may occur in application A, while it isrunning methods(2.3), structure of sm-pathways: every sm-pathway(shared-memory pathway) S that delivers messages having a uniquesoftware memory component called virtualMemory M, embedded in S, thevirtualMemory M embedded in sm-pathway S being called S.vM, no twodistinct sm-pathways using the same virtualMemory, virtualMemories beingdeclared during definition of sm-pathways, real memories being assignedto virtualMemories during compile or run time, S.vM holding messagesdelivered to ports in a port-group of one or more ports connected to S,S.vM also holding messages written by parent-cells of ports connected toS, in addition, S.vM holding computer program codes to process messagesin S.vM and write new messages into S.vM by parent-cells of portsconnected to S, each S.vM having software agents attached to it, noagent being attached to more than one virtualMemory, the set of allagents attached to S.vM being called S.agents, agents in S.agents beingused by S to route, coordinate and synchronize message transfers viapathway S, to enforce message security, and to drive mechanisms that runthe SMS (Self-Monitoring System) of TICC™-Ppde, the mechanisms embeddedin pathways for running SMS being the unique feature that distinguishesTICC™-Ppde pathways from all other communication pathways used in allother computer programming systems, each port being connected to S bybeing connected one unique agent attached to S.vM, all ports connectedto any one agent in S.agents constituting a port-group, pG, it beingpossible for a port-group to contain only one port, distinct ports in pGbeing attached to distinct cells, no two ports of the same cell being inany port-group, distinct port-groups being connected to distinct agentsin S.agents, C.p being a port in pG attached to cell C, the pathway Sconnected to C.p being called C.p.pathway, C.p.pathway=S, and thevirtualMemory of C.p.pathway being called C.p.vM, C.p.vM=S.vM=pG.vM, allports in pG having the same virtualMemory associated with them, no twopathways being ever connected to the same port, no two ports C.p and C.qattached to the same cell being connected to the same pathway unless[C.p, C.q] belonged to a vector of ports called port-vector of the cell,every port C.p giving access to data and methods in pG.vM=C.p.vM only toits parent-cell C, no other cell in A:cells() other than parent-cells ofports connected to a pathway S being able to access data and methods inS.vM, components in a pathway that exchange signals being always tunedto each other, such tuning enabling each component in the pathway to bealways ready to receive and respond immediately to signals sent to it byother components in the pathway, thereby speeding up message transfersconsiderably, each port C.p being automatically tuned to the agentconnected to it at the time the connection is established, agentsattached to C.p.vM and exchanging signals also being tuned to each otherat the same time, also at the time C.p is tuned to an agent attachedC.p.vM both C.p and its parent-cell C being tuned to C.p.vM, thesetunings happening automatically when a pathway is connected to itsports, union of S:ports(), the set of all ports connected to S,S:agents() the set of all agents in S and S.vM being called thecomponents of pathway S, all components in sm-pathways being softwarecomponents, no two sm-pathways ever sharing any components in common,thereby eliminating message interference during simultaneous parallelmessage transfers, FIGS. 2, 17, 19 and 23 showing examples ofpoint-to-point, self-loop, group-to-group and ring-pathways,respectively, FIGS. 1 and 3 illustrating sm-pathways with novirtualMemories, such sm-pathways exchanging only signals and nomessages, FIGS. 2, 4, 19 and 23 illustrating sm-pathways withvirtualMemories, called Das-Pathways, TICC™-Ppde providing methods forinstalling sm-pathways in A:TICC™-network() and modifying them;methods(2.4), structure of dm-pathways: the structure of a dm-pathway(distributed-memory pathway) D_(i) for 0≦i<N in TICCNET™ beingillustrated in FIG. 24, D_(i) being connected to a generalPortport-group pG_(i0) in an SMP, shown on the left of FIG. 24, thedistributed computing network consisting of n SMPs, SMP[j] for 0≦j<n,the index j in SMP[j] being a function of the subscripts i and 0 inpG_(i0) written as j=f(i,0), SMP[j] being thus written as SMP[f(i,0)],pathway D_(i) connecting the generalPort port-group pG_(i0) inSMP[f(i,0)], to functionPort groups pF_(ik) 1≦k<m<n, in other distinctSMPs, SMP[f(i,k)], of the same distributed computing network,f(i,k)≠f(i,0), pG_(i0).vM being the virtualMemory shared in common byall generalPorts in pG_(i0), and similarly pF_(ik).vM being thevirtualMemory shared by all functionPorts in pF_(ik), pG_(i0).vM beingin the SMP, SMP[f(i,0)=j], pF_(ik).vM for 1≦k<m<n being in the SMP,SMP[f(i,k)], the set of all (m+1) virtualMemories in the dm-pathwayD_(i) being called D_(i).vMs, D_(i).vMs[0]=pG_(i0).vM,D_(i).vMs[k]=pF_(ik).vM for 1≦k<m<n, D_(i).vMs={D_(i).vMs[k]|0≦k<m},there being two agents, a₀[i,k] and a₁[i,k] attached to eachvirtualMemory D_(i).vMs[k], a₀[i,k] being a software agent and a₁[i,k]being a hardware agent, all ports in pG_(i0) being connected and tunedto the software agent a₀[i,k], a₁[i,k] being connected to hardwaresignal and data lines of D_(i) as shown in said FIG. 24, the hardwaresignal and data lines thus interconnecting all agents a₁[i,k] for 0≦j≦mlinking pathway segments [pG_(i0)

a₀[i,0]

a₁[i,0]] in SMP[f(i,0)] to the set of all pathway segments {[a₁[i,k]

a₀[i,k]

pG_(ik)]|1≦k≦m}, the segment [pG_(i0)

a₀[i,0]

a₁[i,0]] being called the message sending probe, the segments [[a₁[i,k]

a₀[i,k]

pG_(ik)]|1≦k≦m] being called message receiving probes, each SMP havingmultiple message sending and message receiving probes connecting it tothe TICCNET™, the resulting dm-pathway D_(i) being written asD_(i)=[pG_(i0)

a₀[i,0]

a₁[i,0]

{[a₁[i,k]

a₀[i,k]

pG_(ik)]|1≦k≦m}, port-group pG_(i0) broadcasting message in parallelthrough the probe [pG_(i0)

a₀[i,0]

a₁[i,0]] and via hardware signal and data lines connected to a₁[i,0] toagents a₁[i,k] in the message receiving probes in the set {[a₁[i,k]

a₀[i,k]

pG_(ik)]|1≦k<m_(i)}, the message receiving probes delivering the messageto every port-group pF_(ik) simultaneously, port-groups in{pF_(ik)|1≦k<m} sending back response messages in sequence one after theother in a multiplexed mode to pG_(i0), no two dm-pathways sharingcomponents in common, there being thousands of such distinct dm-pathwaysD_(i), 0≦i<n>1000 in a TICCNET™, TICCNET™ providing mechanisms todynamically install and dismantle such dm-pathways, each installeddm-pathway remaining in TICCNET™ until it is dismantled and a newpathway being installed, all dm-pathways in TICCNET™ together beingcapable of exchanging thousands of messages in parallel simultaneouslywithout mutual interference, TICCNET™ providing guaranteed high-speedparallel message deliveries with latencies of the order of 500nanoseconds plus signal transmission times, these being the uniquefeatures of TICCNET™, TICC™-Ppde providing methods for installingdm-pathways in A:TICC™-network(), dismantling installed pathways and/ormodifying them, the set of all agents in application A in all itssm-pathways and dm-pathways being called A:agents(), the set of allvirtualMemories in application A being called A:virtualMemories();methods(2.5), structure of virtualMemories: each virtualMemory, M,containing four components, (i) readMemory M.rd, (ii) writeMemory M.wr,(iii) executionMemory M.ex, and (iv) scratchPad M.sp, for a C.p.pathwaywith virtualMemory C.p.vM=M, C.p.rd=M.rd, C.p.wr=M.wr, C.p.ex=M.ex,C.p.scp=M.scp, C.p.rd being used by the parent cell C of C.p to readmessage delivered to C.p by C.p.pathway, C.p.wr being used by C to writenew message and send it out via C.p.pathway, the read/write memories ofM being switched before message delivery so that each message receivingcell always reads its delivered message from its readMemory, C.p.exbeing used by C to run methods that process received messages in C.p.rdand C.p.wr, write message into C.p.wr, for any two distinct portsC_(i).p and C_(j).p in a port-group, pG, attached to distinctparent-cells C_(i) and C_(j), C_(i).p.vM=C_(j).p.vM=pG.vM=M, M being thecommon virtualMemory of all ports in the port-group,C_(i).p.sp=C_(j).p.sp==pG.sp=M.sp being the common scratchPad memoryused by parent-cells of ports in pG, M.sp being used by parent-cellsC_(i) of all ports C_(i).p in pG to exchange data with each other whileprocessing in parallel messages in M, in order to coordinate theirrespective computations and send back a joint response, M providingexecution environment for all computer program codes residing in M,TICC™-Ppde providing methods for installing virtualMemories in pathwaysand modifying them; methods(2.6), CCPs and protocols: each port C.p inA:ports() and each pathway C.p.pathway having a software protocol calledC.p.protocol defined for it, each C.p.protocol containing concatenationsof the special programming primitive unique to TICC™-Ppde, called CCPs(Causal Communication Primitives), introduced in Section 1.1 of CHAPTER3, each CCP having the form X:x→Y, X and Y being cells, or ports oragents in a pathway, x being a start or completion signal,concatenations of CCPs having the form X:x→Y:y→Z, X, Y and Z being allcomponents in the same pathway and x, y being signals, it being possiblefor each type of signal to have subtypes defined for it, execution ofCCPs in C.p.protocol causing components in C.p.pathway to exchangesignals between each other, the signals so exchanged traveling overC.p.pathway eventually establishing a context, the said context causingthe message in C.p.vM to be ultimately delivered to intended recipientports also connected to the same C.p.pathway in the case of sm-pathways,the said context causing the message in C.p.vM to be transported tovirtualMemories of intended recipient port-groups via hardware signaland data lines in the case of dm-pathways, the CCPs appearing inprotocols being possibly embedded in other programming languagestatements as described in Section 1, FIGS. 3 and 4, and Section 7,statements (7.1) through (7.4) of CHAPTER 3, none of the protocols inTICC™-Ppde containing data-declarations and all of them containing CCPs,C.p.protocol being invoked and executed only by the parent cell C ofport C.p, TICC™-Ppde providing prepackaged and compiled protocols forexchanging messages via all kinds of pathways likely to be used in anyTICC™-Ppde parallel program, implementers having the responsibility todefine only unusual protocols that may be needed in application A, in amanner that is consistent with the protocol definition formats used inTICC™-Ppde, TICC™-Ppde providing methods for defining protocols usingCCPs; methods(2.7), for tuning components in a pathway: components inC.p.pathway, connected to any port C.p of cell C exchanging signals totransport and deliver message in the virtualMemory C.p.vM to itsintended recipients, components in C.p.pathway being always tuned toeach other, tuning causing components in C.p.pathway to be always readyto receive and immediately respond to signals sent by other componentsin C.p.pathway, tuning eliminating need for synchronization sessionsduring signal exchanges thereby speeding up message exchangesconsiderably, tuning a port C.p to components in C.p.pathway beingaccomplished automatically in TICC™-Ppde at the time C.p.pathway isconnected to C.p, tuning C.p to components in C.p.pathway causing parentcell of C.p also to be tuned to the unique virtualMemory C.p.vM ofC.p.pathway, there being no need for implementers of application A totune components in a pathway, or to schedule or synchronize signalexchanges, scheduling message exchanges via pathways being doneautomatically during TIP executions, scheduling signal exchanges amongpathway components being automatically done by CCPs in protocols,coordinating message dispatch and synchronizing message deliveries beingdone by agents on pathways, agents in a pathway also managing signalexchange mechanisms for driving the SMS of TICC™-Ppde during messagetransmissions and enforcing message security, as described in Section 7of CHAPTER 3, all tuning, coordination, synchronization and support fordriving SMS being built-in features of all TICC™-Ppde protocols, all ofthese capabilities being automatically enabled by TICC™-Ppde whenpathways are installed and connected to their respective ports inA:implementation(), implementers having nothing to do to implement, orinvoke and execute any of these features of any installed pathway in anyapplication, TICC™-Ppde providing methods for installing pathwaycomponents in abstract pathways and tuning the components to each other;methods(2.8), for data protection and parallel buffering: each port C.pin a port-group allowing its parent cell C to access and use itsvirtualMemory C.p.vM, if and only if the said parent cell has eitherjust sensed a message delivered to port C.p, or sensed readiness of portC.p to send out a message, multiple ports in a port-vector, C.p=[C.p₁,C.p₂, . . . , C.p_(n)] attached to the same parent cell givingsimultaneous access to the parent cell C to all virtualMemoriesC.p_(i).vM for 1≦i<≦n when necessary, ports thus allowing theirrespective parent cells to access virtualMemories only when needed, itbeing never possible for parent cells of message sending ports andparent cells of message receiving ports connected to a pathway to bothuse the virtualMemory of that pathway simultaneously, it also beingnever possible for any parent cell of any port not connected to apathway to access the virtualMemory of that pathway, thereby protectingdata in virtualMemories from unauthorized access and use, thereby alsopreventing mutilation of data in virtualMemories and preserving the datain every virtualMemory until the said data are used by their intendedusers, thus the virtualMemories in A:implementation() providingprotected parallel buffering, supporting all asynchronous parallelcommunications in A:implementation(), it being possible to designindependent hardware Shared-Memory Modules, called SMMs, in the sizerange of 10 megabytes to a few gigabytes and dynamically assign the SMMsto virtualMemories during compile or run time, dynamically connectingthe CPU that runs a cell to SMMs only when ports of the cell give accessto their parent cells to virtualMemories associated with those SMMs,such memory organization providing intrinsic security, privacy andprotection to all data and software in an application, privacy andprotection being thus built into a system at its lower most level,TICC™-Ppde thus providing methods for automatic data protection in anyapplication, application programming having nothing to do in order tobenefit from these built-in protection mechanisms; methods(2.9),guaranteed high-speed parallel communications: CCPs implemented insoftware taking 25 to 50 nanoseconds to execute in a 2-gigabertz CPU, itbeing possible to implement CCP as a machine instruction in a CPU, CCPimplemented as a machine instruction taking only about 5 nanoseconds toexecute in a 2-gigahertz CPU, point-to-point communications viasm-pathways requiring at most only six CCP executions (including agentsthat drive the SMS and enforce data security), group-to-groupcommunications via sm-pathways taking up to 14 or more CCP executionsdepending on the number of ports in each port-group, group-to-groupcommunications via dm-pathways requiring 30 or more CCP executionsdepending on the number of port-groups connected to the dm-pathways, noprotocol execution ever invoking any data, program, process or threadnot already defined in that protocol itself, such protocol executionschanging only data already defined in the pathway of that protocol andnothing else, it thus being true that no operating system or any othermonitoring system may schedule, synchronize or execute any part of anyprotocol, no protocol execution being ever interrupted while it is beingexecuted, the entire protocol, C.p.protocol at each port C.p inA:ports() being executed uninterrupted only by the parent cell C of C.pas soon as C completes writing into C.p.vM the message to be sent out,such automatic immediate scheduling of message transmissions, mutualtuning of components in pathways that exchange signals and eliminationof need for sequential buffering in asynchronous communications,enabling very high speed guaranteed instantaneous asynchronouscommunications with latencies of the order of at most a few hundrednanoseconds, when protocols are executed by 2 gigahertz CPUs and CCPsare implemented as machine instructions, both sm-pathways anddm-pathways enabling simultaneous asynchronous parallel messagetransfers, the numbers of such asynchronous parallel message transfersoccurring simultaneously in an application being limited only by thenumbers of distinct pathways installed in that application, thesenumbers being in the range of tens of thousands or more, TICC™-Ppde thusproviding methods for guaranteed automatic high-speed parallelcommunications; methods(2.10), automatic coordination of group-to-groupmessage exchanges with one or more ports in each port-group: portsC_(i).p for 0≦i<n>0 in a port-group pG being connected to distinct portsD_(j).q in another port-group qG, 0≦j<m>0 by a common group-to-grouppathway, pG.pathway=qG.pathway, either the set of all parent cells,D_(j), of ports in qG being distinct from the set of all parent cells,C_(i), of ports in pG, or pG≡qG being true, each C_(i).p.pathway for i,0≦i<n being a part of pG.pathway and each D_(j).q.pathway for j, 0≦j<mbeing a part of qG.pathway≡pG.pathway, these pathways being similar todiagrams shown in FIG. 19 or 17 of CHAPTER 3, or the diagram in FIG. 24,parent cells C_(i) of ports C_(i).p in port-group pG executingasynchronously and in parallel the protocols C_(i).p.protocol in orderto send out a joint service request message, m, via pG.pathway to theports D_(j).q in qG, simultaneous asynchronous parallel executions ofC_(i).p.protocol by parent cells C_(i) over the same group-to-grouppG.pathway being automatically coordinated by agents in pG.pathway, thesaid agents guaranteeing simultaneous synchronous parallel delivery ofthe joint service request message m from ports in pG to every port in qGexactly once, the said agents delivering a message to a port only ifthat port satisfies an a priori defined security condition for thatmessage, the said agents also sending signals to SMS (Self-MonitoringSystem) activating the SMS to install message dispatch and messagedelivery events in SMS for the message being transmitted via pG.pathway,the group-to-group protocols C_(i).p.protocol locking the port C_(i).pimmediately after C_(i).p sends out message m, thereby preventing everyC_(i).p in pG from sending out a second service request message, eachC_(i).p in pG being allowed to send a second service request messageonly after that C₁.p has received from all D_(j).q in qG a jointresponse message, m′, to the service request message, m, it beingfurther required, each C_(i) sense the receipt of m′ at C_(i).p beforeC_(i) can send out a second service request message, m′ being alwayssent back by D_(j).q in qG via the same group-to-group pathway,qG.pathway≡pG.pathway, through which each D_(j).q received the servicerequest message m, TICC™-Ppde thus providing methods for automaticcoordination and synchronization of group-to-group message exchanges;methods(2.11), uniqueness of TICC™-Ppde pathways: TICC™-Ppde providingmethods for the following six pathway capabilities: (i) all pathwaysbeing able to simultaneously transport and deliver messages in parallelwith each other without mutual interference, (ii) all pathwayscontaining built-in infrastructure to drive SMS (Self-Monitoring System)of TICC™-Ppde and enforce data security, (iii) all pathways transmittingmessages asynchronously as soon as messages are ready with no need formessage scheduling or synchronization sessions during messagetransmission, (iv) all software or hardware components that exchangesignals in each pathway being always tuned to each other, tuningenabling every component to be always ready to receive and immediatelyrespond to signals received from other components in that pathway,thereby significantly speeding up message deliveries, (v) every pathwaysending a coordinated joint message from parent-cells of ports in oneport-group and synchronously delivering in parallel that joint messageto ports either in the same port-group or to ports in another port-groupalso connected to the same pathway, (vi) every pathway providingguaranteed high-speed synchronized message deliveries to ports in aport-group with latencies of the order of a few hundred nanoseconds orless with precisely predictable bounds on those latencies, assuming2-gigahertz CPUs, these six capabilities of TICC™-Ppde pathways togethermaking TICC™-Ppde pathways unique and different from communicationpathways used in all other computer communication systems, includingpathways used in TICC™, TICC™-Ppde providing methods to install and usepathways with the above unique characteristics; methods(2.12), fordefining A:cells(): methods for defining a collection of softwarecomputing units called cells, A:cells() being the set of all cells inapplication A, each cell being an instance of a class of cells, theclass of cells being a subclass, hereinafter called Cell-Subclass, ofthe top level abstract TICC™-Ppde class, called Cell, each cell inA:cells() running in parallel with all other cells in A:cells(), eachcell running in a designated distinct CPU (ComPuting Unit) unique tothat cell, no two cells sharing the same CPU, TICC™-Ppde managing allCPU assignments to cells and activations of cells to run in theirrespective assigned CPUs, cells and communication pathways beingspecifically designed to efficiently run in arbitrarily large numbers ofCPUs in a diversity of multi-core chips, cells also being specificallydesigned to run time critical Cyber Physical Parallel Software Systemsin a diversity of multi-core chips, the design, verification andself-monitoring methodologies of TICC™-Ppde being also used to design,verify and run asynchronous hardware components in any AsynchronousHardware Systems, TICC™-Ppde cells being particular specializations ofTICC™ cells, it being the responsibility of implementers to define allTICC™-Ppde cell subclasses (hereinafter referred to as Cell-Subclasses)needed for application A in a manner that is consistent withCell-Subclass definition formats in TICC™-Ppde, TICC™-Ppde providingmethods to define Cell-Subclasses and install cell instances inA:TICC™-networks(); methods(2.8), for defining A:ports(): software portsbeing attached to cells in A:cells(), cells in A:cells() using the portsattached to them to send/receive messages, each port being an instanceof a class of ports, the class of ports being a subclass, hereinaftercalled Port-Subclass, of the top level abstract port class of TICC™-Ppdecalled Port, each port being attached to only one cell C in A:cells(),C.p being any port p attached to cell C, A:ports() being the set of allports attached to cells in A:cells(), C:ports() being the set of portsattached to cell C, each C:ports() for each C in A:cells() having atleast one generalPort called C.g, at least one functionPort called C.f,and at least one interruptPort called C.i, each C.g being an instance ofthe subclass of Port called GeneralPort, C.g being used by C to send outservice request messages and receive back responses, each C.f being aninstance of the subclass of Port called FunctionPort, C.f being used byC to receive and respond to service request messages, each C.i being aninstance of the subclass of Port called InterruptPort, InterruptPortitself being a subclass of FunctionPort, interruptPort C.i being used byC to receive and respond to interrupt messages received from other cellsin A:cells(), it being never possible for any process not run by cellsin A:cells() to interrupt activities of any cell, TICC™-Ppde containingdefinitions of all Port-Subclasses likely to be used in any TICC™-Ppdeparallel program, each port being an instance of a Port-Subclass,TICC™-Ppde providing methods to define Port-Subclasses, install portinstances and attach the port instances to cells, it being theresponsibility of implementers to define only special Port-Subclassesthat are specific to application A and not already defined inTICC™-Ppde, in a manner that is consistent with Port-Subclass definitionformats in TICC™-Ppde; methods(2.9), for defining A:agents(): methodsfor defining software agents, agents being attached to virtualMemoriesof pathways in A:pathways(), each agent being an instance of a class ofagents, the class of agents being a subclass, called Agent-Subclass, ofthe top level abstract agent class of TICC™-Ppde, called Agent, eachagent being attached to only one virtualMemory called parentvirtualMemory of the agent, thus preventing contention for agents frompathways in A:pathways(), A:agents() being the set of all agentsattached to virtualMemories in A:pathways(), TICC™-Ppde containingdefinitions of all Agent-Subclasses likely to be used in TICC™-Ppdeparallel programs, each agent being an instance of an Agent-Subclass,TICC™-Ppde providing methods to define Agent-Subclasses, install agentinstances and attach agents to virtualMemories, it being theresponsibility of implementers to define only special Agent-Subclassesthat are specific to application A and not already defined inTICC™-Ppde, in a manner that is consistent with Agent-Subclassdefinition formats in TICC™-Ppde; methods(2.10), for definingA:virtualMemories(): methods for defining software objects calledvirtualMemories, each virtualMemory being an instance of a class ofvirtualMemories, the class of virtualMemories being a subclass, calledVirtualMemory-Subclass, of the top level abstract virtualMemory class ofTICC™-Ppde, called VirtualMemory, each instance of virtualMemory beinguniquely associated with only one sm-pathway, called parent pathway ofthe virtualMemory, thus preventing contention for virtualMemories fromsm-pathways in A:pathways(), each dm-pathway interconnecting a group ofSMPs in a distributed computing system, each such dm-pathway containingas many virtualMemories as there are SMPs connected to that dm-pathway,A:virtualMemories() being the set of all virtualMemories embedded inpathways of A:pathways(), TICC™-Ppde containing definitions of allVirtualMemory-Subclasses likely to be used in TICC™-Ppde parallelprograms, TICC™-Ppde providing methods to defineVirtualMemory-Subclasses, install virtualMemory instances in pathways,and dynamically assign hardware memories to virtualMemories, it beingthe responsibility of implementers to define only specialVirtualMemory-Subclasses that are specific to application A and notalready defined in TICC™-Ppde, in a manner that is consistent withVirtualMemory-Subclass definition formats in TICC™-Ppde; methods(2.11),for defining A:pathways(): each pathway being an instance of a class ofpathways, the class of pathways being a subclass, hereinafter calledPathway-Subclass, of the top level TICC™-Ppde abstract class calledPathway, pathways in shared-memory environments containing only softwarecomponents, such shared-memory pathways being called sm-pathways,pathways in distributed-memory environments containing both software andhardware components, such distributed-memory pathways being calleddm-pathways, the term pathway being used to refer to both sm-pathway anddm-pathway, the set of all pathways in application A being calledA:pathways(), TICC™-Ppde providing definitions of all Pathway-subclassesfor pathways likely to be used in parallel programming, each pathwaybeing an instance of a Pathway-subclass, TICC™-Ppde providing methods todefine Pathway-subclasses, install pathway instances of and connectpathway instances to ports attached to cells in A:TICC™-network(),implementers having to define only Pathway-Subclasses that are specificto given applications and not already defined in TICC™-Ppde,implementers being required to define all needed new Pathway-Subclassesas per rules of Pathway-Subclass definitions in TICC™-Ppde;methods(2.12), for defining A:TICC™-Network(): TICC™-Ppde providingmethods to install cell instances of abstract or fully refineddefinitions of Cell-Subclasses in A:DESIGN(), cell instances soinstalled belonging to A:cells(), methods for installing instances ofabstract or fully refined definitions Port-Subclasses, and attachingport instances to cell instances in A:cells(), the set of all portinstances attached to cells in A:cells() being called A:ports(), methodsfor installing instances of abstract or fully refined specifications ofPathway-Subclasses and connecting them to ports in A:ports(), the set ofall such pathway instances installed in a design of an application Abeing called A:pathways(), each sm-pathway S in A:pathways() thattransmits messages having a unique instance of virtualMemory, calledS.vM, S.vM being the virtualMemory embedded in S, each dm-pathway Dcontaining one virtualMemory in each SMP connected to that dm-pathway,the number of virtualMemories embedded in D being equal to the number ofSMPs connected to D, D.vMs being the set of all virtualMemories embeddedin the dm-pathway D, each virtualMemory in each pathway having attachedto them unique agent instances of abstract or fully refinedAgent-subclasses, the set of all such agent instances attached tovirtualMemories of pathways in A:pathways() being called A:agents(),pathways in A:pathways() interconnecting ports attached to cells inA:cells(), each port being connected to exactly one agent in exactly onepathway, components of any sm-pathway S in A:pathways() being S:ports(),S:agents() and S.vM, components of any dm-pathway D in A:pathways()being D:ports(), D:agents() and D.vMs, no two distinct pathways sharingcomponents in common, thereby preventing message interference duringparallel message exchanges, A:TICC-network() (hereinafter called thenetwork) being the graph whose nodes are cells in A:cells(), and whosebranches are pathways in A:pathways() that interconnect ports attachedto cells, TICC™-Ppde providing methods to define A:TICC™-Network();methods(2.13), for building A:TICC™-Network(): one or more distinguishedcells of a Cell-Subclass called Configurator (or Environment) beingdefined for application A, A:DESIGN() containing at least one instanceof Configurator called configurator (or environment) in each SMP, theconfigurator having been programmed to install, on cue from a user ofapplication A, a starting sub-network of already definedA:TICC-network() in each SMP sufficient to start application A runningin CPUs assigned to cells in the starting sub-networks, the cells in thestarting sub-network in each SMP having been programmed to install inparallel, using their respective initialization routines, the parts ofA:TICC-network() belonging to that SMP, TICC™-Ppde providing methods toinstall all needed instances of abstract or fully refined subclasses ofcells, ports, agents, virtualMemories and pathways in the network,methods to connect, attach and tune them to each other satisfying allTICC™-Ppde connectivity rules, it being the responsibility ofimplementers to program the initialization routines defined in cellsubclasses suitably so that the network is correctly built onceapplication A is started with the said starting sub-network in each SMP,it also being the responsibility of implementers to develop computerprograms for the initialization routines in a manner that preventsdeadlocks from occurring during parallel network construction in eachSMP, parallel building of the network being automatically coordinated byTICC™-Ppde, TICC™-Ppde providing methods to build already definedA:TICC™-Network(); methods(2.14), for displaying A:TICC™-network():TICC™-GUI (Graphical User Interface) being used to displayA:TICC-network() on a display screen, each SMP having its own dedicateddisplay screen, opening the TICC™-GUI screen for application A causingTICC™-GUI to display on the display screen of each SMP an image of theconfigurator for application A, user clicking on the displayed image ofconfigurator and selecting install option from a displayed menu causingthe configurator in that SMP to install all cells and pathways in astarting subnet of A:TICC-network() sufficient to start running theinitialization routines of cells in the starting subnet of that SMP,each cell in the starting subnet running in a CPU of said SMP assignedto it by TICC™-Ppde, cells in the starting subnet installing other cellsand other pathways in A:TICC-network(), each newly installed cellautomatically getting activated by TICC™-Ppde to run in an assigned CPUof said SMP, each such newly installed cell executing its owninitialization routine to install yet other cells and pathways in thenetwork in said SMP, the network thus growing in parallel until theentire network is built in all SMPs, it being the responsibility ofimplementers to define the initialization routines in a manner avoidingconflicts and deadlocks so that required network is correctly built,TICC™-GUI displaying the installed network in each SMP or parts of thenetwork anchored on cells specified by a user, examples of such networkimages for small applications in a single SMP being illustratedthroughout the CHAPTER 3, TICC™-GUI being a built-in subsystem ofTICC™-Ppde, TICC™-Ppde providing methods to display any part of aninstalled A:TICC™-Network() in any application, A; methods(2.15), fordefining A:messages(): messages being held by virtualMemories ofpathways in A:pathways(), each message being an instance of a class ofmessage, the class of messages being a Msg-subclass, called Msg, of thetop level abstract message class of TICC™-Ppde, called Message, Msgreferring to any Msg-subclass of Message, each Msg definition specifyingmessage formats and data formats that may appear in message instances,m, of Msg, each Msg definition also specifying Msg-methods forprocessing messages and creating new message instances of Msg, pathwaysin A:pathways() delivering instances of Msg-subclasses to ports C.pattached to cells C in A:cells(), the set of all Msg-subclases definedfor application A being called A:messages(), it being the responsibilityof implementers to define all Msg-subclases needed for application A, ina manner that is consistent with message subclass definition formats inTICC™-Ppde, TICC™-Ppde providing methods for defining A:messages() ;methods(2.16), defining Msg-methods: virtualMemory M embedded inC.p.pathway of a port C.p attached to a cell C in A:cells() beingC.p.vM, the readMemory of C.p.vM being C.p.rd, C.p.wr being thewriteMemory, C.p.rd holding a message instance m of a Msg-subclass Msg,the phrase C.p:msg() referring to this message instance m, C.p.wrholding a message instance m′ of possibly another Msg-subclass Msg′,C.p.wr:msg() referring to this message instance m′, the CPU that runsparent cell C of C.p executing Msg-methods defined in the Msg-subclassesMsg and Msg′, the executionMemory C.p.ex providing execution environmentto each Msg-method defined in the Msg-subclasses, Msg and Msg′Msg-methods and Msg′-methods defined in Msg-subclasses, Msg and Msg′,respectively, having the formats Msg:<method-name>(<ports>) andMsg′:<method-name′>(<ports′>), all ports C.q appearing in the argument<ports>, and all <ports′> being attached to the parent cell C of portC.p, CPU running cell C using C.p:<method-name>(<ports>) andC.p:<method-name′>(<ports′>), respectively, to invoke and execute therespective methods in C.p.vM, these methods using data and other methodsdefined only in the following components associated with cell C, portC.p and other ports C.q appearing in <ports> or <ports′>, the componentsbeing, (i) cell C, (ii) port C.p, (iii) messages C.p:msg() andC.p.wr:msg(), (iv) ports C.q appearing in the argument <ports> or<ports′> and (v) messages C.q:msg() and C.q.wr:msg() residing invirtualMemories C.q.vM, any cell C executing any method defined in anyMsg-subclass or in a Cell-subclass of C being able to use only data andother methods defined in other software components in pathways connectedto ports of C, such pathways being always connected to ports of C,tuning and attachment being symmetric relations, these featuresisolating each cell C from all other cells in A:cells(), parent-cells ofmessage sending and message receiving ports connected to a pathway neverusing the virtualMemory of that pathway simultaneously, TICC™-Ppdeproviding methods for defining Msg-methods as per rules given above;methods(2.17), for defining A:pthreads(): Msg-methods,Msg:<method-name>(<ports>), defined in any Msg-subclass, Msg, orsimilarly defined cell methods, C:<method-name>(<ports>), defined in anyCell-subclass, being called pthreads (parallel threads) since suchmethods are likely to be short sequential computer programs taking nomore than 10 to 100 microseconds to complete execution in a 2 gigahertzCPU, pthreads being executed in parallel by cells in A:cells(), the setof all such pthreads defined for application A being calledA:pthreads(), each pthread in A:pthreads() being independent of allother pthreads in A:pthreads() excepting pthreads executed in parallelby parent-cells of ports in a port-group in their common virtualMemory,M, and using M.sp to exchange data during parallel execution of the saidpthreads in order to coordinate their, respective, parallelcomputations, TIPs isolating pthreads from all communications amongcells, it being the responsibility of implementers to fully refine allabstract software units in A:implementation() including pthreads andMsg-subclasses, update A:requirements() during refinement, formalvalidation of A:implementation() being possible at any stage ofrefinement of A:implementation(), TICC™-Ppde providing methods fordefining refinements for pthreads as per rules given above.
 3. Methodsas recited in claims 1 or 2 further including methods for implementingA:DESIGN() through successive refinements to produce fully refinedA:implementation(): methods(3.1), for defining programming abstractionscalled TIPs (Thread Interaction Protocols): TICC™-Ppde provides methodsfor defining abstract specifications of interactions among cells inA:cells() using TIPs, each TIP being defined at a port C.p of cell C,TIP defined at port C.p being called C.p:TIP(), there being a C.p:TIP()defined at each port attached to each cell C in A:cells(), the set ofall TIPs defined for a cell C being called C:TIPS(), the set of all TIPsdefined for application A being called A:TIPS(), C.p:TIP() specifyingabstractly how cell C receives message at its port C.p, processes thereceived message and responds to it, or cell C builds a message andsends it out via port C.p, interactions among cells in A:cells()occurring only through messages exchanged via pathways inA:TICC-network(), the essential difference between TICC™-Ppde and othersimilar systems based on message exchanges being in the way TICC™-Ppdemanages communications, each cell in TICC™-Ppde itself delivering allmessages with no need for message scheduling and synchronizationsessions, guaranteeing very high speed instantaneous asynchronousparallel message deliveries with precisely predictable latencies in therange of at most a few hundred nanoseconds using 2 Gigahertz CPUs, onlyfive different kinds of TIPs being necessary to cover the needs of allparallel programming, five kinds of TIPs called synchronous TIPs andfive kinds called asynchronous TIPs, simple TIPs have the forms,Synchronous TIP: C.p:TIP()=C.p:<guard>?(){C.p:tip()}  (C.1)Asynchronous TIP: C.p:TIP()=C.p<guard>?()*{C.p:tip()}  (C.2) where Cevaluates the synchronous guard C.p:<guard>?() in (C.1) to check whetherport C.p has a message delivered to it, executes C.p:tip() if C.p has amessage delivered to it, else C skips port C.p polls its next port, whenC evaluates the asynchronous guard C.p<guard>?()* in (C.2) it waits atport C.p until a message is delivered to C.p, executes C.p:tip() whenmessage is delivered and then only polls its next port, C.p beingconnected to exactly one agent attached to the virtualMemory C.p.vM ofC.p.pathway, C.p:tip() being called the TIP-body, execution ofC.p:guard?() or C.p:guard?()* at port C.p being called polling of C.p bycell C, the order in which cell C polls its ports being called thepolling-cycle of C, the various kinds of TIPs needed to define anyparallel program in TICC™-Ppde being described in Chapter 3, examplesusing various kinds of TIPs appearing throughout Chapter 3, it being theresponsibility of implementers to define C.p:TIP() for each port inA:ports() in a manner that is consistent with TIP definition formats inTICC™-Ppde and intended design requirements of application A, TICC™-Ppdeproviding methods for defining TIPs; methods(3.2), Asynchronous guards:C.p:guard?() in statement (C.1) being an asynchronous guard having oneof the forms C.p:mR?() (‘mR’ for ‘messageReady’) and C.p:pR?() (‘pR’ for‘pathwayReady’), asynchronous guard being a condition implemented as abuilt-in computer program provided by TICC™-Ppde, available for use inany implementation, implementers being free to define their own guardsspecific to given applications, A, not already defined in TICC™-Ppde,guards being always based on signals or subtypes of signals exchanged byports in application A, asynchronous guards being used by cell C inA:cells() to poll its ports C.p to check whether C.p has a messagedelivered to it, or whether C.p is ready to send out a message, theguards returning truth values true or false the TIP-body C.p:tip() instatement (C.1) being executed only if the guard returns truth valuetrue, the TIP-body being skipped if the guard returns false, TIPs withasynchronous guards being called asynchronous TIPs, TICC™-Ppde providingmethods for defining asynchronous guards; methods(3.3), Synchronousguards: C.p:guard?()* in statement (C.2) being a synchronous guard, theparent cell C executing the TIP-body only if C.p:guard?()* returns true,else waiting at port C.p, repeatedly executing C.p:guard?() untilC.p:guard?()* returns truth value true, executing the TIP-body instatement (C.2) when C.p:guard?()* becomes true, then only proceeding topoll its next port, the symbol ‘*’ appearing in the synchronous guardindicating to TICC™-Ppde the need for this kind of repeated execution ofthe computer program implementing the guard until the guard returnstrue, TIPs with synchronous guards being called synchronous TIPs,TICC™-Ppde providing methods for defining synchronous guards;methods(3.4), for simple TIP execution at a functionPort: assuming C.pin (C.1) refers to a functionPort C.f attached to cell C, C being theunique parent cell of C.f, C being the only cell that may use C.f, C.freceiving a joint service request message, m, from one or more otherports C′.q, the message m received by C.f being stored in the readMemoryC.f.rd of the virtualMemory C.f.vM≡M, the virtualMemory M being embeddedin C.f.pathway, phrase C.f:msg() denoting the message in C.f.rd, themessage C.f:msg() delivered to C.f being sensed by cell C throughevaluation of the guard C.p:<guard>?()=C.f:mR?() (′mR?()′ for ‘messageReady?’) appearing in (C.1), evaluation returning truth value truecausing cell C to respond to C.f:msg() by executing the TIP-bodyC.p:tip()=C.f:r().s(); appearing in statement (C.2), C.f:r() (‘r’ for‘respond’) being the abstraction of a pthread (parallel thread) used byC to process the service request message C.f:msg() and write theresponse message in the writeMemory, C.f.wr of C.f.vM, theexecutionMemory, C.f.ex, of C.f.vM providing execution environment forthe evaluation of this TIP-body C.p:tip(), implementers being free touse any name for the pthread ‘r()’ in C.f:tip(), name used byimplementers capturing the design intent for r(), parent cell C of C.fevaluating C.f:s() immediately after evaluating C.f:r() to invoke andexecute eval(C.f.protocol) in order to transmit the response messagewritten in C.f.wr immediately to ports C′.q from which C.f received itsservice request message, execution of this protocol causing theread/write memories of C.f.vM to be switched before message delivery sothat each C′.q receives the response message written in C.f.wr in thereadMemory C′.q.rd, it being also possible for C to execute C.f:f()instead of C.f:s() in order to forward a message received in C.f.rd backto its sender or senders, possibly with some modifications, C.f:f() notswitching the read/write memories, cell C itself evaluating theprotocol, C.f.protocol, associated with port C.f, in order to send offor forward the response message with no need for message scheduling orsynchronization sessions, TICC™-Ppde providing methods for executing allkinds of TIPs at functionPorts, as discussion in Sections 2 and 4 ofChapter 3; methods(3.5), simple TIP execution at a generalPort:Supposing C.p in (C.1) is a generalPort C.g of cell C, C being theunique parent cell of C.g, C being the only cell that may use C.g,generalPort C.g being used by cell C to send out service requestmessages and receive response messages, C executingC.p:<guard>?()=C.p:pR?() (‘pR?()’ for ‘pathway Ready?’) in (C.1),C.p:pR?() returning truth value true, cell C then executingC.p:tip()=C.g:tip()=C.g:x().s() (‘x()’ for ‘construct’), the pthreadC.g:x() being the abstraction whose refined form is executed by C in theexecutionMemory, C.g.ex, of C.g.vM, C.g:x() being executed in order tocompute, construct and write a service request message in C.g.wr, andimmediately thereafter C itself executing C.g:s() to invoke and executeeval(C.g.protocol), in order to send that service request message inC.g.wr to one or more ports, C′.q, the read/write memories of C.g.vMbeing switched before message delivery so that each C′.q receives theservice request message in its readMemory C′.q.rd, it being alsopossible for C to execute C.g:f() instead of C.g:s() in order to forwarda message received in C.g.rd back to its sender or senders, possiblywith some modifications, without switching the read/write memories, cellC itself evaluating the protocol, C.g.protocol, associated with portC.g, in order to send off or forward the message with no need formessage scheduling or synchronization sessions, TICC™-Ppde providingmethods for executing all kinds of TIPs at generalPorts; methods(3.6),for defining five kinds of synchronous TIPs: the five kinds of TIPsbeing, (i) simple TIPs introduced in statements (C.1) and (C.2), (ii)spawning TIPs that spawn computations in other cells in A:cells() inorder to respond to a service request, spawning TIPs being introduced inSections 4.1 and 4.2 of CHAPTER 3 in statements (4.1) through (4.3) andstatements (4.11) through (4.13), (iii) TIPs servicing port-vectors,introduced in Section 4.2 of CHAPTER 3, in statements (4.8) through(4.13), (iv) TIPs with non-deterministic guards and existential guards,introduced in Section 4.4 of CHAPTER 3, in statements (4.14) and (4.16),(v) TIPs containing in its TIP-body other embedded TIPs, introduced inSection 4.5 CHAPTER 3, in statements (4.18) through (4.23), any embeddedTIP being any one of these five kinds of TIPs, it thus being possiblefor all the above kinds of TIPs to appear in any combination in theTIP-body of a single TIP, these five kinds of synchronous TIPs andcorresponding asynchronous TIPs being the only kinds of TIPs needed todesign and build any TICC™-Ppde software or hardware system, TICC™-Ppdeproviding methods for defining all kinds of TIPs; methods(3.7), fortransaction completion: ports C_(i).p for 0≦i<n, in port-group pGsynchronously delivering a joint service request message m to all portsD_(j).q in port-group qG for j, 0≦j<m, by simultaneous coordinatedparallel execution of eval(C_(i).p.protocol), for 0≦i<n, this parallelevaluation of C_(i).p.protocol by each C_(i) being automaticallycoordinated by agents in pG.pathway, each port C_(i).p being immediatelylocked soon after C_(i) begins evaluation of C_(i).p.protocol, each portD_(j).q being immediately locked when the parent cell D_(j) of D_(j).qsenses the message m delivered to D_(j).q, thus preventing a secondservice request message from being received at D_(j).q, the port D_(j).qreceiving delivery of a second service request message only after thefirst service request message m has been processed and responded to byall parent cells D_(j) by sending a joint response message, m′, via allports in qG, the port C_(i).p sending a second service request messageonly after all parent cells C_(i) have sensed the joint response messagem′ sent by qG, each parent cell D_(j) asynchronously evaluating theprotocol, D_(j).q.protocol, in parallel with other parent cells of portsin port-group qG, in order to send the response message m′ over the samegroup-to-group pathway, qG.pathway≡pG.pathway, this parallel executionof said protocols by parent cells D_(j) being again coordinated byagents in qG.pathway, said agents guaranteeing simultaneous delivery ofjoint response message m′ exactly once to every port C_(i).p in pG,sensing of this response message m′ received at ports C_(i).p by parentcells C_(i) constituting for each C_(i) completion of the transactionthat started when C_(i).p sent its service request message m to D_(j).q,thus each port in A:ports() sending successive service request messagesonly after successive transaction completions and similarly each port inA:ports() receiving successive service request messages only aftersuccessive transaction completions, each port always sending backresponse message via the same pathway through which that port receivedits service request message, TICC™-Ppde providing methods for guaranteedorderly completion of all parallel transactions without mutualinterference; methods(3.8), for defining correctness of transactions:transaction between any two ports p and q in A:ports() being written as[p(srm(t₁))

q(rm(t₂))], p(srm(t₁)) being the service request message sent by port pat time t₁ and q(rm(t₂))) being the response message sent back by port qat time t₂, the said transaction being correct if only if for allmessages p(srm(t₁)) and g(rm(t₂)) the relation R_((p,q))(srm(t₁) rm(t₂))is true, R_((p,q)) being the name of a relation that is specific to theport pair (p,q) and in addition the timing restrictiont₂−t₁≦τ_(max)(p,q)) is also true τ_(max)(p,q) being an upper bound onthe delay that may occur before the transaction between p and q iscompleted, ports p and q being well-matched if and only if everytransaction between p and q is correct, this well-matched property ofports being dependent on the TIPs, p:TIP() and q:TIP() and also being animportant property in TICC™-Ppde, the property being referred to severaltimes in these claims, the timings and bounds associated withtransactions being estimated at the time of design and verified afterimplementation of pthreads and conditions in the TIPs, fully refinedA:implementation() being correct if and only if all pairs of portsconnected by pathways in A:TICC™-network() are well-matched, TICC™-Ppdeproviding methods for validating satisfaction of well-matched propertyof pairs of ports connected by pathways in A:implementation();methods(3.9), for defining abstractions called CIPs: a computer programcalled C:CIP() (Cell Interaction Protocol of C) being specified byimplementers for each cell C in A:cells(), C:CIP() specifying aninitialization routine C:CIP-init(), for the cell C, initializationbeing done only once, at the time C is started, C:CIP-body() specifyingthe order in which C may poll its ports C.p and execute C.p:tip() whenappropriate for each one of its ports, C:CIP-body() polling ports C.p ofcell C cyclically one after the other, this cyclic polling and TIPexecution being called the polling cycle of cell C, C continuing itspolling cycle until C terminates its operations or C suspends itsoperations as a result of receipt of an interrupt message from anothercell in A:cells() at one of the interruptPorts of C, C being suspendedonly between successive TIP executions in its polling cycles, it beingimpossible to suspend a TIP execution in the middle of its executionunless programmed suspension is built into a TIP-body as discussed inSection 8.2 of Chapter 3, suspended C resuming execution later at thetime next message is delivered to any of the ports of C, execution ofC.p:TIP() for any port C.p being not synchronized with messagedeliveries to C.p, polling C.p by cell C succeeding only if C.p had beendelivered a message before the time at which C.p was polled in a pollingcycle, message at C.p missed in one polling cycle being caught in thenext polling cycle, C:CIP() for each cell C running in parallel withC′:CIP() of all other cells C′ in A:cells(), each cell being run in itsown unique and distinct designated CPU, polling cycles of distinct cellsin A:cells() being not necessarily synchronized with each other,TICC™-Ppde providing ad hoc synchronization and coordination methods, asdescribed in Section 6.6 of CHAPTER 3, to coordinate and synchronizepolling cycles of distinct cells in A:cells() at any point during theimplementation of application A without having to change any of therefinements done up to that point, A:CIPS() being the set of allcomputer programs C:CIP() for every cell C in A:cells(), it being theresponsibility of implementers to define C:CIP() for each cell C inA:cells() in a manner that is consistent with CIP definition formats inTICC™-Ppde and intended functionality of cell C in A:implementation(),TICC™-Ppde providing methods for defining CIPs; methods(3.10), twopossible execution modes in polling cycles of CIPs: C.p returning truthvalue true when it was polled by cell C causing C to follow one of twopossible courses actions, (i) executing the TIP-body C.p:tip()immediately and responding to the received message, or (ii) insertingC.p into a sortedPortsList of cell C, sorting usually being done basedon time stamps at ports indicating message delivery times in the localclock of the CPU that runs the cell, such time stamps being set at thetime of message delivery to ports by protocols that deliver messages toports, or sorting being done according to any sorting relation local tocell C, after completing polling and sorting all its ports, C executingC.p:tip() for each C.p in the sortedPortsList in the order it appears inthe list, C.p returning truth value false when it was polled by cell Calso causing C to follow one of two possible courses actions (i)skipping port C.p and immediately proceeding to poll its next port ifthe guard at C.p is an asynchronous guard, or (ii) waiting at port C.pfor a message to arrive, executing C.p:tip() after the message arrivesand then only proceeding to poll its next port if the guard at C.p is asynchronous guard, it being also possible for a CIP to executeTIP-bodies at some of its ports immediately after the guard of the TIPreturns truth value true and sort other ports into the sortedPortsListfor later execution, TICC™-Ppde providing methods to specifysorted/unsorted and synchronous/asynchronous executions of TIPs by CIPs;methods(3.11), for defining and using port-groups: port-groups beingcollections of ports belonging to distinct cells in A:cells(), no twoport-groups having any port in common, no two ports attached to the samecell being ever in a port-group, port-group being defined by connectinga group of distinct ports attached to distinct cells to an agent in apathway, agents in each group-to-group pathway dispatching messageswritten jointly by parent cells of ports in a message sending port-groupafter all the said parent cells have completed writing their respectivecontributions to the joint message, the dispatched message beingdelivered synchronously to all ports in the message receivingport-group, dispatch and delivery of messages between ports inport-groups thus being always synchronous, agents in the pathwayconnecting port-groups coordinating all message dispatches anddeliveries in the said pathway, agents also coordinating installation ofcorresponding message dispatch and delivery events in SMS (SelfMonitoring System) and enforcing data security during message deliveriesby delivering messages to ports only if the (port, message) pairsatisfies an a priori specified security condition, each parent cell ofports in the message receiving port-group sensing and responding to thereceived message at its own time, even though the said message wassynchronously delivered to all ports in the message receivingport-group, port-groups thus providing mechanisms in TICC™-Ppde toimplement synchronous forks and joins of parallel processes inapplication A, TICC™-Ppde providing mechanisms to define port-groups andinstall group-to-group pathways, and providing protocols for messageexchanges over all group-to-group pathways likely to be used in parallelprogramming, TICC™-Ppde providing methods also for defining and usingport-groups; methods(3.12), for defining and using port-vectors: cellshaving one or more port-vectors defined for them, each port-vectorconsisting of two or more ports attached to the same cell, ports in aport-vector being all of the same kind, either all generalPorts or allfunctionPorts or all interruptPorts, the notation C.p being used torefer to a port-vector of cell C, C.p=[C.p₁, C.p₂, . . . , C.p_(k)],k≧2, parent cell of C.p polling the ports in C.p in every one of itspolling cycles, each C.p_(i) for 1≦i≦k being connected to a distinctpathway, C.p_(i).pathway, each C.p_(i) for 1≦i≦k receiving messagesindependently of each other through C.p_(i).pathway from distinct cellsother than C, in each polling cycle the parent cell responding tomessages received at ports C.p_(i) only after all ports in C.p havereceived messages, else the parent cell skipping all ports in theport-vector C.p in that polling cycle, the simplest TIP at port-vectorC.p having the form Asynchronous C.p:TIP( ) = (C.p₁:mR?( ) & C.p₂:mR?( )& ... &       C.p_(k):mR?( )){ C:r(p); C.p₁:s( );...;C.p_(k):s( );} or(C.3) Synchronous C.p:TIP( ) = (C.p₁:mR?( ) & C.p₂:mR?( ) & ... &        C.p_(k):mR?( ))*{ C:r(p); C.p₁:s( );...;C.p_(k):s( );}, (C.4)

 where C:r(p) is a pthread defined and executed in the private memory ofcell C, C:r(p) using messages received at every port C.p_(i) for 1≦i≦k,the received message residing in distinct virtualMemories C.p_(i).vM for1≦i≦k, each C.p:TIP() responding unconditionally to every port in C.p,it being possible for C.p:TIP() to be any one of the five kinds of TIP,port-vectors being used in applications both to implement asynchronousforks and joins of parallel pthread computations and to implement ad hocsynchronization and coordination of computations performed by cells asdescribed in Section 6.6 of CHAPTER 3, TICC™-Ppde providing methods fordefining and using port-vectors; methods(3.13), for group-to-grouptransactions: each pathway in A:implementation() being connected to agroup of one or more message sending ports in a port-group, pG, eachport in pG belonging to a distinct parent-cell, all ports in pG beingconnected to the same agent, a0, in the group-to-group pathway,pG.pathway, pG.pathway connecting ports in pG to a group of one or moreother ports in another port-group qG, all ports in qG being connected toanother agent, a1, in qG.pathway≡pG.pathway, in a manner shown in FIG.19, it being also possible that pG≡qG and a0≡a1 as shown in FIG. 17, thesaid pathway always transmitting message only in one direction, fromparent cells of message sending port-group pG or qG to parent cells ofmessage receiving port-group qG or pG, respectively, ports in a messagesending port-group pG always sending a joint service request message toports in port-group qG, ports in qG always sending back to ports in pG ajoint response message through the same qG.pathway, ports inports-groups pG and qG thus always exchanging only joint-messagesjointly written and jointly synchronously received by all parent cellsof ports in port-groups pG or qG, agents in pG.pathway≡qG.pathwayautomatically guaranteeing coordinated dispatch and synchronousdeliveries of all such joint-messages over the said pathway, agents alsoautomatically coordinating installations of corresponding messagedispatch and delivery events in SMS (Self-Monitoring System) for everymessage sent or received by every port in port-groups pG or qG, parentcell of each port in qG sensing and responding to the service requestmessage at its own time in one of its polling cycles, polling cycles ofdifferent cells not being necessarily synchronized to each other orsynchronized to message delivery times, each port in qG responding backto ports in pG via the same qG.pathway≡pG.pathway, all ports in pG andqG having the same virtualMemory associated with them, pG.vM≡qG.vM, amessage exchange transaction between ports in pG and ports in qG beingcompleted only when all parent cells of ports in pG have received andsensed the joint response message sent by parent cells of ports in qG,pG being well-matched to qG iff every port in pG is well-matched toevery port in qG, TICC™-Ppde thus providing methods for defining andusing well-matched group-to-group transactions; methods(3.14), forguaranteed timely transaction completions with predictable timings:TICC™-Ppde enabling timely completion of every transaction inapplication A with in predictable time bounds by, (i) guaranteeing, nocell C ever misses sensing any service request message delivered to anyof its ports, C.p, (ii) automatically activating the TIP-body ofC.p:tip() at every port C.p of cell C in A:cells() after C sensesreceipt of a service request at a port C.p, (iii) making it impossiblefor any process or cell in A:implementation() or outsideA:implementation() to interrupt execution of C.p:tip() once it has beenactivated, (iv) guaranteeing completion of every transaction started byreceipt of service request message at any port C.p, (v) guaranteeingpredictable timely response to every received service request at everyport C.p of every cell C in A:cells() through elimination of instructionscheduling delays in CPUs that might be caused by use of speed-uptechniques such as multiple instruction-stream executions, look-aheadscheduling, pipe-lined processing and cached executions, or any otherkind of ornamentation of instruction scheduling in CPUs, these speed uptechniques being not necessary in TICC™-Ppde parallel programs to gainhigh throughputs, high throughputs being achieved in TICC™-Ppde parallelprograms through arbitrary scaling of small grain size parallelprocesses, execution of any C.p:tip() taking no greater than 10 to 100microseconds to complete, (vi) transaction completions being alwayscaused only by TIP executions, (vii) transaction scheduling andcoordination being always caused automatically by orderings of ports inpolling cycles of cells in A:cells() and orderings of TIP executionsinduced by orderings of message deliveries to ports in A:ports(), (viii)transaction synchronization being always caused by automaticsynchronization of message deliveries in group-to-group transactions anduse of ad hoc synchronization techniques described in Section 6.6 ofCHAPTER 3, (ix) all TIP executions in A:implementation() beingself-synchronizing and self-coordinating, (x) implementers beingresponsible only to define C.p:TIP() for every port C.p in A:ports()using TIP formats provided by TICC™-Ppde for various kinds of TIPsmaking sure every pair of ports connected by a pathway is well-matchedand define C:CIP() for every cell C in A:cells() consistent with CIPdefinition formats in TICC™-Ppde and intended functionality of eachC:CIP(), (xi) all message exchanges in A:TICC™-network() beingself-synchronizing and self-coordinating, (xii) all of these featurestogether providing guaranteed timely transaction completions withpredictable timings for all transactions in A:implementation(),TICC™-Ppde thus providing methods for guaranteed timely transactioncompletions; methods(3.15), for tuning preservation: guaranteed andtimely transaction completions in turn maintaining and guaranteeingmutual tuning of components in each pathway in A:pathways() thatexchange signals with each other, state changes caused in the componentsof a pathway by signal exchanges during message transmission in onedirection causing all components in the pathway to be ready for messagetransmission in the other direction, and message transmission in theother direction automatically resetting said states of all components inthe pathway to their well tuned initial states, as described in Section1.2 of CHAPTER 3, thereby always guaranteeing high-seed asynchronouscommunications in A:implementation() with no need for synchronizationsessions, TICC™-Ppde thus providing methods for automatic tuningpreservation; methods(3.16), for coordinating joint processing ofmessages in virtualMemories by parent cells of ports in port-groups: allports C_(i).p in a port-group pG for 0≦i<n, always having an identicalmessage delivered to them synchronously and this message residing in thereadMemory C_(i).p.rd≡pG.rd, both the message and the readMemory beingcommon to all ports C_(i).p in pG, the number of ports in pG usuallybeing in the 1 to 16 range, parent-cells of ports in pG executing theirrespective C_(i).p:tip() in parallel in order to process and respond tothe same message synchronously delivered to all of them, parent-cell ofeach C_(i).p in pG responding to the received message in its own duecourse in one of its polling cycles, parent-cells C_(i).p for 0≦i<n notnecessarily responding to the received message synchronously, however,each parent-cell C_(i) executing C_(i).p:tip() in the same virtualMemorypG.vM≡C_(i).p.vM in parallel with parent-cells of all other ports in theport-group pG, virtualMemory pG.vM≡C_(i).p.vM providing a commonscratchPad memory, pG.sp≡C_(i).p.sp, for all parent-cells C_(i) of portsC_(i).p in order to exchange data with each other during such parallelC_(i).p:tip() executions, the parent-cells C_(i) achieving correctcoordination by exchanging said data with each other through pG.spduring execution of C_(i).p:tip(), it being the responsibility ofimplementers to write computer programs for pthreads in C_(i).p:tip()for ports C_(i).p in pG enabling such coordination using pG.sp andinstall where necessary pthread locks to enforce coordinated updates ofcommonly shared data, such pthreads executed in parallel by parent-cellsof ports in a port-group being the only pthreads in A:pthreads() thatmay be mutually dependent on each other, TICC™-Ppde thus providingfacilities for coordinated joint parallel processing by cells incell-groups; methods(3.17), for completing A:implementation(): methodsfor completing A:implementation() through successive refinements ofabstract TIPs and CIPs in A:DESIGN(), and abstract Msg-subclass inA:messages(), decomposition of compound cells, C, into sub-networks ofcells interconnected by pathways and encapsulation of sub-network insidethe compound cells, refinements thus consisting of defining computerprograms that implement the abstract pthreads, abstract conditions andabstract Msg-subclasses and decomposition and encapsulation of compoundcells, all pthreads defined as per rules of TICC™-Ppde, allMsg-subclasses being defined satisfying formats given in top levelabstract Message class of TICC™-Ppde, the set of all pthreads,conditions, Msg-subclasses and encapsulated cells defined inA:implementation() at any stage of refinement being, respectively,called A:pthreads(), A:conditions(), A:messages() and A:cells(), at eachstage of refinement A:implementation() containing A:TICC-Network(),A:TIPS(), A:CIPS(), A:messages(), A:pthreads(), A:conditions(),A:definitions(), A:cells and A:requirements() defined up to that stageof refinement, A:definitions() consisting of logical characterizationsof all pthreads, methods and conditions, TICC™-Ppde providing methodsfor successively refining abstract specifications and completingA:implementation(); methods(3.18), mutual independence of TIPsassociated with distinct cells and mutual independence of pthreads &conditions appearing in those TIPs: each TIP-body C.p:tip() at a portC.p of a cell C in A:cells() or TIP-body of a port-vector, C.p:tip()being executed only by parent-cell C, all ports appearing in C.p:TIP()and C.p:TIP() being attached to the same parent-cell C, thevirtualMemory C.p.vM providing the execution environment for executingC.p:tip(), the private memory of parent-cell C providing the executionenvironment for executing the port-vector TIP-body, C.p:tip(), duringexecution of C.p:tip() or C.p:tip() the cell C using only data and othermethods defined in cell C and ports appearing in C.p:TIP() or C.p:TIP()and methods defined in software components in pathways connected toports appearing in C.p:TIP() or C.p:TIP() and tuned to or attached toeach other, the executed pthreads changing only data associated withparent cell C and ports used in the execution and nothing else, thus allpthread and TIP executions by distinct cells being mutually independent,excepting those pthreads that share data through scratchpad memory tocoordinate parallel executions by parent-cells of ports in a port-group,at any stage of refinement using logical input/output characterizationsof pthreads, methods and conditions described in validating computerprograms of said pthreads, methods and conditions and for jointlyvalidating computer programs of pthreads and conditions that share datathrough scratchpad, TICC™-Ppde providing methods that exploit mutualindependence of TIPs and pthreads in order to validate computer programsdefining TIPs and pthreads; methods(3.19), predicates used to describestates of software components: state of any software component, x, beingdefined by Boolean combinations of predicates having the form(x.attribute=data), (x.attribute₁<y.attribute₂),(x.attribute₁<y.attribute₂), (x.attribute₁εy.attribute₂) or(x.attribute₁εy.attribute₂), etc., x and y being cell C, or a port C.pof cell C, or any component of C.p.pathway or any data item inC.p.rd:msg() or C.p.wr:msg(), C.p.rd:msg() being the message in C.p.rdand C.p.wr:msg() being the message in C.p.wr, states being used todefine input/output characterizations computer programs definingpthreads, states being used also to define conditions implemented bycomputer programs, TICC™-Ppde providing methods to characterize statesof software components in A:implementation(); methods(3.20), logicalinput/output characterizations of pthreads, methods and conditions: forany pthread or method P(), its characterization having the form,{

pre_(P)-C?()

(t₁) &

m:C?()

(t₁)}[

P()(t₁)

(t₂)]{post_(P)-C?()(t₂) & m′:C?()(t₂) & R_(P)(m,m′)(t₂) &((t₂)≦(t₁+τ_(max)(P))},  (C.5)  pre_(P)-C?() and post_(P)-C?() beingpre-condition and post-condition associated with P(), these conditionsspecifying states of software components in which the pthread P() isbeing executed, m:C?() being the condition that characterizes the statepf input message m processed by P(), m′:C?() being the condition thatcharacterizes the state of output message m′ produced by P(),R_(p)(m,m′) being the relation between m and m′ that should be satisfiedevery time P() is executed, ‘→’ being the symbol that denotes executionof P(), execution of P() beginning at the same time t₁ when pre_(P)-C?()and m:C?() become true, execution of P() terminating at time P() whenall of post_(P)-C?(), m′:C?(), R_(p)(m,m′) and ((t₂)≦(t₁+τ_(max)(P))become true, τ_(max)(P) being the maximum time it may take to completeexecution of P(), each condition in (C.5) being a Boolean combination ofstates of one or more software components in which the condition isevaluated, the software components being all either attached to eachother or tuned to each other, the computer program for P() being correctif and only if the logical characterization of P() given in (C.5) holdstrue, every time P() is executed, the definition of the computer programfor a condition being correct if and only if evaluation of that computerprogram returns true if and only if the Boolean combination ofpredicates defining the said condition is true, the set of logicalcharacterizations of all pthreads, methods and conditions inA:implementation() defined during refinements being calledA:definitions(), TICC™-Ppde providing interactive tools to characterizeall pthreads and methods used in an implementation; methods(3.21), cellisolation and program mobility: an important property of TIP being,formats of TIPs defined at ports are independent of the kinds ofpathways connected to those ports, TIPs integrating communications withcomputations in the sense each cell by itself evaluates protocolsassociated will all of its ports, there being no difference betweencomputations performed by a cell to process and build messages andcomputations performed by the same cell to transmit messages, messageprocessing/building computations and protocol evaluations in a TIP-bodynever being interleaved with each other, protocol evaluations alwaysoccurring only after all computations to process and build messages havebeen completed in the TIP-body, TIPs thus isolating communications fromcomputations performed by cells in each TIP-body, TIPs also isolatingparallel computations performed by different cells in A:cells(), theprotocol at a port being always executed in the virtualMemory of thatport, data defining state of cell C being held in the private memory ofcell C, and data defining states of ports attached to cell C being heldin the respective virtualMemories of those ports, the virtualMemoriesand private memories of cells C thus providing distinct executionenvironments for distinct cells, two distinct cells in A:cells() thatare not parent-cells of ports in a port-group being able to execute inparallel at the same time copies of the same pthread or protocol indistinct virtualMemories or distinct private memories of cells,parent-cells of ports in a port-group being able to execute in parallelat the same time the same pthread in the same virtualMemory commonlyshared by all ports in the port-group, execution of pthreads andprotocols always changing only the states of cells that perform thoseexecutions and states of pathways associated with protocols and nothingelse, thereby isolating parallel computations performed by cells inA:cells() from each other, cell isolation enabling program mobility in aparallel computing system between two ports C₁.p and C₂.p of distinctcells C₁ and C₂ with distinct virtualMemories C₁.p.vM and C₂.p.vM,program mobility being achieved by transporting entire contents of thevirtualMemory C₁.p.vM, with the state of the parent cell C₁ copied intoC₁.p.vM, to the virtualMemory C₂.p.vM, TICC™-Ppde thus guaranteeing cellisolation and program mobility; methods(3.22), dependent and independentports of cells: each cell C in A:cells() having multiple generalPorts,functionPorts and interruptPorts, a port C.p or a port-vector C.p ofcell C being independent only if computations performed during executionof C.p:tip() or C:tip(C.p) depend only on message(s) delivered to C.p orC.p and the state of C.p or C.p and nothing else, it being possible forcell C to have more than one such independent port or port-vector, inall other cases ports of C being dependent on each other, the simplestC.p:tip() for port C.p dependent on port C.q having the formC.p:mR?(){C.p:r(C.q).s();} with the pthread C.p:r(C.q) being used forprocessing and responding to message received at port C.p, the pthreadC.p:r(C.q) having C.q as its argument, this argument enabling C.p:r(C.q)to use the current state of C.q and messages in C.q.vM as well as stateof C.p and messages in C.p.vM while responding to message received atC.p, it being possible for more than one port to appear in the argumentof such a response method C.p:r(C.q), execution of TIPs at dependentport being coordinated as described in Section 4.5 of CHAPTER 3, itbeing possible to move dependent and independent ports from one cell toanother duplicate of that cell in certain cases, as described in thesaid Section 4.5, TICC™-Ppde providing methods to define TIPs so thatall port dependencies are properly taken care of; methods(3.23) forinterrupt handling: no Operating System may ever interrupt computationsbeing performed by any cell C in A:cells(), cell C being interruptedonly through receipt of interrupt messages at its interruptPorts, suchinterrupt messages being sent to cell C by other cells in A:cells(),receipt of interrupt messages at interruptPorts of cell C being servicedby cell C only once in each polling cycle, or each interruptPortsignaling the CPU that runs cell C using CCP (Causal CommunicationPrimitive) at the time an interrupt message is delivered to it and theCPU responding to it only between successive TIP executions, low grainsize TIP executions, made possible by low message exchange latencies inhundreds of nanosecond range, enabling interrupts to be responded towith no more than 10 to 100 microseconds delays even though interruptsare processed only between successive TIP executions, an interruptmessage being received at an interruptPort of cell C causing cell C toperform any one of the following: (i) suspending the operation of cell Cat the end of its current TIP execution, the suspended operation beingautomatically resumed, at the next TIP to be processed, by receipt ofnext message at any port of the cell C, mechanisms for such suspensionand resumption of computations in cells being automatically handled bycell C itself without need for Operating System intervention, (ii)dynamically changing the order of TIP executions in cell C, or (iii)terminating operation of cell C and releasing the CPU assigned to cellC, all of these happening only between successive TIP executions, itbeing the responsibility of implementers to ensure that cell C servicesall pending as yet unserviced service request messages received at itsports before termination, TICC™-Ppde providing methods so that no TIPexecution is ever interrupted while at the same time all interrupts arepromptly attended to; methods(3.24) for programmed suspensions: apthread in C.p:tip() at a port C.p in cell C being programmed to suspendits execution in the middle of C.p:tip() execution, cell C proceedingimmediately to poll its next port after suspending its computations inC.p:tip(), such programmed suspensions being caused because conditionsin cell C necessary to make progress in C.p:tip() execution not beingsatisfied at the time of suspension, suspended computations C.p:tip()being resumed automatically in an ensuing polling cycle of cell C whenthe said necessary conditions become satisfied, TICC™-Ppde providingtools for implementing such programmed suspensions, as discussed inSection 8.2 of Chapter 3; methods(3.25) starting parallel computationsin A:implementation(): the environment cell, also called theconfigurator cell, used to set up A:TICC™-network() being used to startcomputations in application A, computations being started by a userclicking on the image of the environment cell displayed by TICC™-GUI andselecting from a displayed menu the option to start computations, theenvironment cell responding to this selected option by sendingpredefined messages to designated ports of designated starting cells inA:cells(), the protocols delivering the said messages to the saiddesignated cells automatically activating said designated cells beforemessage delivery, said designated cells running in CPUs assigned to themby TICC™-Ppde, once activated said designated cells initializingthemselves, if necessary, during such initializations installing therest of A:TICC™-network() if necessary, thereafter each one of the saiddesignated cells starting their, respective, polling cycles and duringthose polling cycles sensing the delivered messages, responding to themand causing computations to spawn over the rest of A:TICC™-network(),TICC™-Ppde thus providing tools to start parallel computations;methods(3.26) stopping parallel computations: while cells in A:cells()are running in their respective assigned CPUs certain designated cellsin A:cells(), responsible to terminate computations, send interruptmessages to the environment cell requesting the environment cell toterminate computations, these termination requests arriving at differentinterruptPorts of an interruptPort-vector of the environment cell, theinterrupt messages arriving at the interruptPorts of the saidport-vector at different times, the environment cell responding to theinterrupt messages received at the said interruptPorts only after allthe said interruptPorts have received interrupt messages, when allinterruptPorts in the said vector have received interrupt messages theenvironment cell broadcasting a termination interrupt message to allcells in application A through one of its generalPorts, each cell inA:cells() receiving the termination interrupt message terminating itselfon sensing receipt of this termination interrupt message, each such cellterminating only after servicing all as yet unserviced pending messagesat its ports and sending back before termination a response message tothe environment cell acknowledging receipt of the termination interruptmessage, agent on the pathway connecting cells in A:cells() to theenvironment cell coordinating all such responses and forwarding to theenvironment cell an acknowledgement message only after all cells inA:cells() that received the termination interrupt message have respondedto that interrupt message, and on receipt of this acknowledgement fromall other cells in A:cells() the environment cell terminating itself, ifnecessary, TICC™-Ppde thus providing tools to stop parallelcomputations; methods(3.27), for defining privileges: each cell C inA:cells() having the ability to dynamically install new ports C.q onitself, install other cells C′ in A:cells(), and install pathwaysbetween said port C.q and ports C′.p of newly installed cell C′, cells Csending requests to install such new cells and pathways to configuratorcells in application A, it being possible for an application to havemore than one configurator cell, the configurator receiving suchrequests checking first whether the cell or cells that requested suchinstallations have the requisite privileges to have the installationsperformed, servicing the installation request only if requisiteprivileges are satisfied, and then responding to the requesting cellsappropriate responses, if requisite privileges are not satisfied theninforming the requesting cells about privilege violations, installationof a new cell or a new pathway taking about 250 microseconds to onemillisecond in a 2 gigahertz CPU, depending upon the number of ports andcells in the installation, installation of a new port taking about 30 to50 microseconds in a 2 gigahertz CPU, configurators issuing privilegeviolation reports when privileges are violated, implementers having theresponsibility to define privileges for cells in A:cells() associatedwith ports that connect the cells to configurators in application A inmanners that satisfy privilege definition formats in TICC™-Ppde, itbeing possible to preinstall spare cells, ports, agents, virtualMemoriesand pathways of various kinds and keep them in a reserve pool, to beused as needed by configurators in application A, thereby speeding upconsiderably dynamic installations of such components, TICC™-Ppdeproviding tools for defining privileges associated with ports inA:ports(); methods(3.28), for defining security functions: as specifiedin Section 7 of CHAPTER 3, an agent in a pathway delivers message to aport only if the port satisfies an a priori specified security conditionfor that message, agent issuing a security violation report if specifiedsecurity condition is violated at the port, all message exchangelatencies including in them times needed for such security checks,implementers of application A having the responsibility to define neededsecurity functions as per specifications in TICC™-Ppde, TICC™-Ppdeproviding tools to define security functions; methods(3.29), accessingexternal data from secondary storage devices and Internet: everyapplication A having certain number of cells in A:cells() dedicated toaccess data from secondary storage devices and/or Internet anddistributing them to virtualMemories of ports requesting such data,cells either sending requests for such data to a configurator, whichforwards the data request to a cell dedicated to obtaining such dataafter checking privileges of cells that requested such data, or cellsalready having requisite privileges installing dedicated newgeneralPorts on themselves, setting up pathways from those generalPortsto cells dedicated to obtaining such data, cells sending requests fordata via the newly established pathways and getting the needed data inreturn, only if a priori specified security functions for that requesteddata are satisfied, TICC™-Ppde thus providing tools to access externaldata; methods(3.30), for dynamic monitoring of an application while itis running using break points: while examining activities of SMS(Self-Monitoring System) using TICC™-GUI in order to monitor a runningapplication is certainly possible, such monitoring will not presentusers data associated with events registered by SMS, thus there is aneed for users to insert break points into TIPs C.p:tip() in order toexamine data associated with events registered in the SMS, installationof break points being illustrated here for simple TIPs having the form,C.p:TIP()=C.p:guard?(){C.p:r().s();}, introduction of such break-pointsrequiring appending to C.p:tip() the phrase, C.g:pR?(){C.g:b().s();} asin the modified C.p:TIP() shown below,C.p:TIP()=C.p:guard?(){C.p:r().s(); C.g:pR?(){C.g:b(C, C.p).s();}},  C.gbeing a free unused generalPort of cell C, a pathway, C.g.pathway beingdynamically established between port C.g and a functionPort of aconfigurator, the pthread C.g:b(C,C.p) being the break-point method,C.g:b(C,C.p) reading and writing into the virtualMemory C.g.vM thestates of cell C and port C.p and also writing into C.g.vM messagesprocessed by or built by C.p:tip() at the time C.g:b(C, C.p) wasexecuted, cell C sending off the message written into C.g.vM to theconfigurator, the configurator causing the received data to be displayedon a screen of TICC™-GUI, it being possible to insert such break-pointsin to TIPs of all kinds, however, since using break-points in thismanner always disrupting timings of events occurring in application A,such break-points being used only in a testing mode of application A,TICC™-Ppde providing tools to define and install such break-points inTIPs; methods(3.31), for encapsulating sub-networks ofA:TICC™-network(): TICC™-Ppde providing methods to encapsulatesub-networks of A:TICC™-network() associated with subsystems, B, ofapplication A into compound-cells, the sub-network encapsulated in acompound-cell for a subsystem B of application A being calledB:TICC™-network(), the compound cell encapsulating B:TICC™-network()being called the compound-cell B, B having two kinds of ports,internal-ports and external-ports, internal-points being the portsattached cells in B:TICC™-network() and external-ports being the portsattached to the compound-cell B, there being a subset of cells inB:TICC™-network() containing internal-ports that are connected toexternal-ports of B by branches, each internal-port being so connectedexactly to one external-port of B, it being possible to connect internalports in a port-group inside the compound cell B to an external port ofB through an internal agent of the compound cell B, the external-portstransmitting immediately signals they receive to the internal-ports theyare connected to, distinct parent-cells in B:TICC™-network() with portsconnected to external-ports of B sensing and responding in parallel tosignals they receive from the external-ports, all other internal-portsof B not so connected to external-ports of B being connected to eachother by internal TICC™-Ppde sm-pathways, compound cell B hiding allcomponents of B:TICC™-network() excepting the internal-ports connectedto external-ports of B, from other cells in A:TICC™-network(), the setof TIPs B.p:TIP() at each external-port B.p of a compound cell, B, beingidentical to the set of TIPs C.p:TIP() defined at the internal-portsconnected to B.p, such encapsulated compound cells, B, each with its ownbuilt-in SMS (Self-Monitoring System), being used as a softwarecomponent, which may be plugged into larger software systems, connectingeach external-port B.p of compound-cell B by a pathway to a port D.q ofa cell D in the larger software system external to B, making sure everypair of ports, (B.p, D.q) is well-matched, ability to thus plug-inencapsulated components into larger networks enabling reuse of softwaresubsystems, examples of such compound cells being illustrated in Section2.2 of CHAPTER 3, TICC™-Ppde providing tools to encapsulate sub-networksof a TICC™-network.
 4. methods recited in claims 1, 2 or 3, furtherincluding following additional methods pertaining to design of CPUs inmulti-core chips in order to efficiently run A:implementation():methods(4.1), for simplification of CPU designs and special CPUrequirements: TICC™-Ppde simplifying designs of CPUs by eliminating theneed to use speed up techniques such as cached executions, multipleinstruction stream executions, look-ahead scheduling of instructions andpipe-lined processing, as explained in Section 4.6 of CHAPTER 3, butTICC™-Ppde requiring a small number of special facilities in each CPUrunning cells in A:cells(), the said special facilities being (i) ahardware clock in each CPU to enable time stamping of message deliveriesto ports attached to a cell run by that CPU, time stamping being done attimes when messages are delivered to said ports, messages beingdelivered in parallel to the ports of said cell, multiple simultaneousmessage deliveries to multiple ports of said cell being possible, suchmultiple simultaneous message deliveries to multiple ports requiringfacilities for the hardware clock of a CPU to be interrogatedsimultaneously by said multiple ports of said cell in order to set timestamps at times of message deliveries (details in Section 8.1 of Chapter3), (ii) requiring each such CPU to implement CCP (Causal CommunicationPrimitive) as a hardware instruction, (iii) requiring interrupt handlingfacilities so that each interruptPort may communicate directly using CCP(Causal Communication Primitive) with the CPU running the parent-cell ofsaid interruptPort, the CPU responding to received interrupt signal onlybetween successive TIP executions of the said cell, and (iv) requiringeach SMP (Shared-Memory Multi-processor) multi-core chip with multipleSMPs of the order of 256 or more in a single chip to have theshared-memory organized with SMMs (Shared-Memory Modules) that exploitvirtualMemory organization in TICC™-Ppde software systems, theserequirements not complicating CPU designs, but however, complicatingchip designs, simplified CPU designs increasing achievable CPU densitiesin multi-core chips, tools provided by TICC™-Ppde to organize andexecute parallel computations thus simplifying CPU designs withoutcompromising execution efficiencies; methods(4.2), for exploitingvirtualMemory organization: designing each CPU in an SMP with only asmall private memory of no more than 10 kilo-words to 1 mega-word, butimplementing each CPU with a capability to dynamically connect to anyone of a collection of independent hardware memory modules usingprogrammable logic networks, these memory modules being called SMM(Shared-Memory Modules), SMMs being kept in a pool of such hardwaredevices, each SMM in the pool having memory capacities in the range of10 kilo-words to 1 giga-word or more, each SMM in the pool allowing nomore than about 16 CPUs to simultaneously access it, assignment of SMMsto virtualMemories being done at compile time or run time, each port C.pof each cell C in A:cells() of an application A dynamically connectingthe CPU, C.cpu, assigned to parent-cell C of C.p to the SMM assigned tothe virtualMemory C.p.vM at compile time or CPU assignment time,granting access to data in C.p.vM to C.cpu only at times when the stateof port C.p, C.p.state=S and only during execution of C.p:tip(),terminating the access immediately after C.p:tip() execution iscompleted (details in Section 8.2 of Chapter 3), and possibly connectingthe same CPU to another SMM associated with the next port of cell C,this scheme enabling high-speed shared-memory accesses with reducedmemory interference, dramatically minimizing memory contention inparallel shared-memory software systems running in multi-core chips withlarge numbers of CPUs of the order of 256 or more, providing intrinsicdata protection, data privacy and system security to any application A,this scheme, however, requiring a memory organization with multiplememory-buses, one for each SMM, each SMM being simultaneouslyaddressable by independently running CPUs connected to them, andprogrammable logic networks for efficiently dynamically changingconnections between CPUs and SMMs at run times, SMMs eliminating onceand for all the damaging legacy of organizing CPUs in SMPs with hugeshared main memories of tens or hundreds of giga-words sizes,simplifying CPU designs, but complicating chip-designs, while at thesame time intrinsically contributing to greater efficiency, greatersoftware security, greater privacy and greater protection, TICC™-Ppdethus enabling arbitrarily scalable secure protected parallelcomputations; methods(4.3), for asynchronous hardware subsystemencapsulation: it being possible to use the same techniques of design,implementation through refinement, requirements specification, formalverification and self-monitoring to implement any asynchronous hardwaresystem, it being possible to use TICC™-Ppde encapsulation techniques toencapsulate hardware subsystems into compound-cells, each suchcompound-cell having its own SMS (Self-Monitoring System), hiding allencapsulated components from other components in a hardware system, eachsuch compound-cell itself being used as a hardware system component,being plugged into larger hardware systems in contexts where allexternal-ports of the compound-cell are well-matched to ports of thelarger system to which they are connected, thereby facilitatingfabrication of multi-core chips, TICC™-Ppde being thus used to designand implement asynchronous hardware systems as well;
 5. Methods asrecited in claims 1, 2, 3 or 4 further including following methods forformally validating A:implementation(): methods(5.1), for derivingA:ALLEOPS() from A:implementation(): methods to automatically derivefrom A:DESIGN() and A:implementation(), at each stage of refinement ofA:implementation(), ALLEOPs (ALLowed Event Occurrence Patterns) modelsof computations specified in the design and implementation, these modelsmaking explicit all event classes implicit in A:DESIGN() andA:implementation(), exhibiting causal chains of said event classes,ALLEOPs models also exhibiting patterns of event classes that may occurin computations specified in the design and implementation, multipleevent instances of each event class in ALLEOPs occurring in computationswhile A is being run, there being two kinds of event classes in ALLEOPs,one kind called action event classes of the form X, action event beingevaluation of a statement in a programming language, or evaluation of acondition, or evaluation of a pthread, the other kind of event classbeing called communication event classes having the formC.p^(S)[T(C.p,#)] for port C.p sending a message or C.p^(F)[T(C.p, #)]for port C.p forwarding a message and C′.q^(D)[T(C.p,#)] for C.pdelivering message to another port C′.q, the terms T(C.p,#) appearing incommunication event classes being called time-maps, each T(C.p,#)referring to a sequence of time instances t₁<t₂< . . . <t_(n), n≧0, atwhich instances of the said event classes C.p^(S), or C.p^(F) orC′.q^(D) occur in a run of A:implementation(), the number sign, #,0≦#<n≧0, (n−1) being the total number of times time-maps with port C.poccurs in a CIP (Cell Interaction Protocol), symbols X and Y beinghereafter used to refer to any of the said event classes, often omittingthe tip-maps when not needed, symbols X and Y or X(t) and Y(t) beingused to refer to instances of event classes, t being the time at whichthe instances occur, pairs of action event or communication eventclasses X and Y in ALLEOPs being linked by weighted directedcausal-links having the form, X^(C(X,Y))→Y, other pairs of event classesin ALLEOPs being linked by causal-links without weights as in X(t)→Y(t),yet other pairs of event classes in ALLEOPs not being so linked by anycausal-link, the causal-link with weight C(X,Y) being interpreted asdescribed later below, multiple instances X(t) for t=t₁<t₂< . . .<t_(n), n≧1, of each event class in ALLEOPs occurring while A is beingrun, TICC™-Ppde providing methods for automatically deriving A:ALLEOPS()from A:implementation() as defined and illustrated in Section 2 ofCHAPTER 3; methods(5.2), for deriving port-ALLEOPs: methods forautomatically deriving port-ALLEOP, C.p:port-ALLEOP() from C.p:TIP(),port-ALLEOP being the ALLEOPs model for C.p:TIP() in A:TIPS(),C.p:port-ALLEOP() having the form,C.p:port-ALLEOP()=C.p:ALLEOP-guard?(){C.p:ALLEOP-body()},  (C.6) methods used for automatic derivation of C.p:port-ALLEOP() fromC.p:TIP() being described in Section 2 of CHAPTER 3 and illustratedusing a sample application called BILL-BEN application,C.p:port-ALLEOP()s providing conveniently modularized descriptions ofALLEOPs of A:implementation() ; methods(5.3), for building ALLEOPsgraphs: the graph of all port-ALLEOPs C.p:port-ALLEOP() inBILL-BEN:ALLEOPS() being illustrated in FIG. 6A, the graph beingobtained by linking port-ALLEOP pairs, C₁.p:port-ALLEOP() andC₂.q:port-ALLEOP() for ports C₁.p and C₂.q attached to distinct cells C₁and C₂ in BILL-BEN:cells(), with weighted directed causal-links^(C(X,Y))→ or directed causal-links → without weights, in a manner thatis consistent with pathway interconnections specified inBILL-BEN:TICC™-network() and TIPs in BILL-BEN:TIPS(), causal-linksrepresenting an irreflexive, transitive and asymmetric causationrelation, all event classes in port-ALLEOPs with causal-linksinterconnecting them and time-maps associated with communication eventclasses being derived automatically by TICC™-Ppde from specifications inA:implementation(), the graph in said FIG. 6A being a representation ofBILL-BEN:ALLEOPS(), TICC™-Ppde providing methods to automatically deriveA:ALLEOPS() from A:implementation() for any application A and constructfor any application, A, the graphical representation of A:ALLEOPS() likethe one shown in said FIG. 6A; methods(5.4), for interpretation ofcausal links in ALLEOPs graphs: each weighted directed causal-linkhaving the form X^(C(X,Y))→Y appearing in ALLEOPs graphs representing aconditional causal-link, each directed causal-link of the form X→Yappearing in said ALLEOPs graphs representing an unconditionalcausal-link, these causal-links being interpreted as follows: ifoccurrence of an event instance X(t₁) of event class X at time t₁ causesan event instance Y(t₂) of event class Y to occur later at time t₂ in arun of A:implementation(), written as X(t₁)→Y(t₂), then there shouldexist either a conditional-causal link X^(C(X,Y))→Y or an unconditionalcausal-link X→Y in the graphical representation of A:ALLEOPS() such thatY(t₂) is an instance of Y and condition C(X,Y) is true at time t₂ in thecase of conditional causal-link or instance Y(t₂) of Y occursunconditionally in the case of unconditional causal-link, and in allcases, t₂−t₂≦τ(X,Y), the upper bound τ(X,Y) being the maximum alloweddelay between occurrences of the two events X(t₁) and Y(t₂) inX(t₁)→Y(t₂), the execution characteristics of parallel programs inTICC™-Ppde making it possible to predict event occurrences with inprecisely defined time bounds, the upper bounds τ(X,Y) being firstestimated by implementers of A from intended or measured running timesof pthread and protocol executions and later confirmed afterexperimentation with the completed A:implementation(), TICC™-Ppdeproviding tools to correctly interpret ALLEOP graphs; methods(5.5), forbuilding the causalnet: the network of event instances of all and onlythe communication event classes in ALLEOPs, with causal-links amongthem, generated automatically by the SMS (Self-Monitoring System) ofTICC™-Ppde during a run of A:implementation() being called the causalnetof A in that run, representation of the set of all possible causalnetsthat may occur in any run of application A being called A:domain(), thecausalnets for the BILL-BEN example being illustrated in FIGS. 6B and 6Cbeing examples of causalnet in BILL-BEN:domain(), different runs of Aproducing different causalnets because of different conditions becomingtrue in different runs, not all ALLEOP-nodes having instances occurringin the causalnet in any given run of A:implementation(), (A:CausalNet()satisfies A:ALLEOPS()) being true if and only if the following logicalcondition holds true, (A:CausalNet( ) satisfies A:ALLEOPS( ))

 [∵(Communication-Event X[t(C.p, #)]) (X[t(C.p, #)]occurringIn A:ALLEOPS( ))   ∴(X,Y)∴(TIME t₁,t₂)(X(t₁) instanceOf X) &   ((X(t₁)→Y(t₂)) occurring-in A:CausalNet( ))]

    [∴(Communication-Event Y[TC′.q, #)]) ∴(TIME-INTERVAL     τ(X,Y))  ((X[T(C.p, #)] →...→ Y[T(C′.q,#)]) occursIn A:ALLEOPS( )) &    (Y(t₂)instanceOf Y[T(C′.q,#)]) &       (t₂ ≦ t₁ +τ(X[T(C.p,#)],Y[T(C′.q,#)]))], (C.7)

 statement (C.7) asserting, A:CausalNet() for application A satisfiesA:ALLEOPS() if and only if for every communication event instance X(t₁)of communication event class X[T(C.p,#)] in A:ALLEOPS() and everycausal-link (X(t₁)→Y(t₂)) occurring in A:CausalNet(), there is acommunication event class Y[T(C′.q,#)] in the graph of A:ALLEOPS() withcausal chain, (X[T(C.p,#)]→ . . . →Y[T(C′.q,#)]) such that Y(t₂) is aninstance of Y[T(C′.q,#)] and t₂≦t₁+τ(X[T(C′.q,#)],Y[T(C′.q,#)]), thecausal chain (X[T(C.p,#)]→ . . . →Y[T(C′.q,#)]) signifying that there isa sequence of one or more event classes linked by causal-links leadingto event class Y[T(C′.q,#)] from event class X[T(C.p,#)] in ALLEOPs,ability to predict event occurrences in causalnets with in preciselyspecified time bounds making it possible to use TICC™-Ppde platform todesign, develop, implement, validate and run with self-monitoringapplications for real time Cyber Physical Parallel Software Systems,TICC™-Ppde providing tools to build causalnets and verify that saidcausalnets satisfy ALLEOPs associated with them in the sense of (C.7);methods(5.6), for deriving automatically A:port-TRACE()s fromA:port-ALLEOP()s: traces generally describing what happens when aprogram is run, different programming disciplines using differentformats to describe traces, traces in TICC™-Ppde describing not onlywhat may happen when A:implementation() is run, but also specifying thesemantics of action events occurring in a run of application A,semantics being specified by conditions under which an alternate in acollection of alternate events may occur in any given run, andspecifying for each action event logical pre-conditions in application Awhich should hold true for that action event to occur and logicalpost-conditions application A that should hold true after the actionevent has occurred, as described in statement (C.5) and in Section 2 andSection 5 of CHAPTER 3 and illustrated in definitions shown inAppendices I through III of CHAPTER 3, the trace for a port-ALLEOPC.p:port-ALLEOP() being called C.p:port-trace(t_(P)), t_(P) being thevirtual-time at which events in C.p:port-trace(t_(P)) may beginoccurring in a run of A:implementation(), TICC™-Ppde providing methodsto automatically derive A:port-TRACE()s from A:port-ALLEOP()s usingspecifications in A:implementation() and specifications inA:definitions() given A:implementation(), TICC™-Ppde providing tools toautomatically derive A:port-TRACE()s from A:port-ALLEOP()s and constructA:domain(); methods(5.7), for deriving Automatically A:ECT-network()from A:domain(): port-ECT (port Event Characterization Table),C.p:port-ECT(t_(P)), for a port C.p in A:ports() being derivedautomatically by TICC™-Ppde from C.p:port-trace(t_(P)),C.p:port-ECT(t_(P)) representing events occurring inC.p:port-trace(t_(P)) in a tabular form that is convenient for formallyproving CTL-assertions (Causal Temporal Language-assertions) given byimplementers of A:implementation(), several examples ofC.p:port-ECT(t_(P)) being presented in Chapter 3, an ECT-network being anetwork of any collection of port-ECTs C.p:port-ECT(t_(P)) withspecified initial conditions, interconnected to each other as perpolling orders defined in CIPs of A:CIPS() and message exchanges definedin C.p:port-ALLEOP() of A:ALLEOPS(), as illustrated in Tables 5 through9, A:ECT-domain() being the combined network containingC.p:port-ECT(t_(P)) for all ports C.p in A:ports(), TICC™-Ppde providingtools to automatically derive ECT-networks from traces; methods(5.8),for design verification: TICC™-Ppde automatically deriving ALLEOP modelsof A:DESIGN() called A:designALLEOPS() using abstract definitions inA:TICC™-network(), A:TIPS() and A:CIPS(), A:designALLEOPS() makingexplicit, synchronization and coordination of all action andcommunication event classes and causal chains of event classes that wereimplicit in A:DESIGN(), methods for deriving A:designALLEOPS() fromA:DESIGN() being defined and illustrated in Section 2 of CHAPTER 3,A:designTRACES() being derived automatically from A:designALLEOPS(),methods for automatically deriving A:designTRACES() fromA:designALLEOPS() being also defined and illustrated in said Section 2,A:designTRACES() allowing users to tentatively associate timings andtiming bounds with all event classes and verify synchronization andcoordination of event classes as well as causal chains of event classesin A:designTRACES(), A:designECT-domain() being automatically derivedfrom A:designTRACES(), A:designECT-domain() being used to formallyvalidate designs, validation criteria being provided by implementers asCTL-assertions in A:requirements(), TICC™-Ppde developing formal proofsfor CTL-assertions in A:requirements() using A:designECT-domain() inorder to validate A:DESIGN(), TICC™-Ppde interacting with users duringdevelopment of formal proofs, users providing guidance for proof searchwhere necessary by providing additional CTL-assertions, methods fordoing these being illustrated in Section 6 of CHAPTER 3, the formalvalidation methods being used to interactively generate counter exampleswhen a required CTL-assertions are found to be not valid in A:DESIGN(),implementer revising designs as needed using the counter examples andrevalidating the design, such validations being also used to guaranteethat A:DESIGN() is free of deadlocks and livelocks, and guaranteeprogress in A:DESIGN(), deadlocks stopping all operations in applicationA if they occur, livelocks, if they occur, freezing up some subsystemsof A preventing them from performing their assigned tasks, while othersubsystems are proceeding normally to perform their tasks, progressguaranteeing that causal chains of event instances of event classesoccurring while application A is being run always satisfyingspecifications in A:designALLEOPS() as defined in (C.7), TICC™-Ppdeproviding tools to interactively verify given designs by evaluatingCTL-assertions over A:designECT-domain(); methods(5.9), for verifyingcorrectness of pthreads: each collection of computer programs forpthreads that interact with each other through a common scratchpad beingjointly formally verified as being correct, computer programs for allother pthreads being independently formally verified as being correct,each computer program implementing a pthread or condition being formallyverified to assure that the computer program satisfies the logicalinput/output characterization given in statement (C.5), this beingpossible because each pthread is a short computer program running onlyfor about 10 to 100 microseconds, proving correctness ofA:implementation() requiring correctness of all pthreads inA:implementation(), TICC™-Ppde providing tools to interactively verifypthreads; methods(5.10), for proving CTL-assertions given byimplementers: TICC™-Ppde providing methods to develop interactive proofsof CTL-assertions (Causal Temporal Logic assertions), structure ofCTL-assertions being informally defined in the last paragraph of Section5.2 in CHAPTER 3 and examples of CTL-assertions appearing in Section 6of CHAPTER 3, specific syntax of CTL-assertions being not as importantas there being an unambiguous interpretation for any CTL-assertion,CTL-assertions given by implementers being validated by evaluating themover ECT-networks, evaluation of CTL-assertions over ECT-networksproducing causal chains of events in the ECT-network that match withgiven CTL-assertions as per matching criteria defined and illustrated inSection 6 of CHAPTER 3, the process of generating causal chains of eventinstances in ECT-network that match with given CTL-assertions beingcalled the proof checking process, guidance for proof checking beingprovided by users, methods for such interactive proof checking beingillustrated in Section 6 of CHAPTER 3, CTL-assertions validated usingECT-networks being valid properties of A:implementation() since theECT-networks used in proof checking are all automatically derived fromA:implementation(), the valid CTL-assertions ultimately verifying thewell-matched property of every pair of ports connected by a pathway inA:implementation(), the well-matched property of pairs of portsconnected by pathways in A:implementation() following from proofs of thefollowing: (i) formal proofs of correctness of pthreads, (ii) formalproofs of progress in A:implementation() indicating every causalnet inA:domain() always satisfies A:ALLEOPS() as defined in statement (C.7),(iii) formal proofs of all CTL-assertions in A:requirements() forA:DESIGN(), (iv) formal proofs that A:implementation() is free ofdeadlocks, (v) formal proofs that A:implementation() is free oflivelocks, examples of such proofs being shown in Section 6 of CHAPTER3, validation of A:implementation() ultimately being dependent on theset of all validated CTL-assertions, TICC™-Ppde providing tools tointeractively verify CTL-assertions using ECT-networks; methods(5.11),for providing guidance to implementers to identify CTL-assertions thatvalidate A:implementation(): guidance to implementers to defineCTL-assertions needed to validate A:implementation() being provided byA:requirements() and the requirement specified in statement (C.8) below,A:requirements() being logical specifications of requirements forapplication A specified in CTL-language by implementers before designingand implementing application A and updated during design and refinement,statement (C.8) providing guidance to specify CTL-assertions needed toverify correctness of A:implementation(): [(A:domain( ) satisfiesA:ALLEOPS( )) &  (A:ALLEOPS( ) satisfies A:requirements( ))]

A:implementation( ) is correct), (C.8)

 implementers using criterion (C.8) and the requirement that all pairsof ports interconnected by a pathways should be well-matched, in orderto ascertain they have not missed validating any needed CTL-assertions,TICC™-Ppde providing methods to assist users by identifying portsconnected by pathways that have not been validated as beingwell-matched, TICC™-Ppde also assisting implementers to interactivelyidentify counter examples that explain why given CTL-assertions are notvalid in A:implementation(), implementers using the counter examples torevise A:implementation() as needed and revalidate the revisedimplementation; methods(5.12), for ad hoc synchronization andcoordination: two events X(t₁) and Y(t₂) associated with two distinctcells in A:cells() and occurring in the causalnet of A:implementation()are incomparable in the sense (t₁≦t₂) may be true in certain runs ofA:implementation() and (t₁>t₂) may be true in certain other runs, itbeing possible, correct operation of A:implementation() requires twosuch incomparable events X(t₁) and Y(t₂) to be either coordinated orsynchronized, coordination of events X(t₁) and Y(t₂) meaning, one ofthem should always occur only after the other one has occurred, forexample it may be required (t₁≦t₂) should hold true in all runs ofA:implementation(), synchronization of events X(t₁) and Y(t₂) meaning(t₁=t₂) should hold true in all runs of A:implementation(), TICC™-Ppdeproviding ad hoc methods to coordinate and synchronize such incomparableevents without having to change any of the refinements inA:implementation(), such ad hoc synchronization and coordination methodsrequiring only that certain new pathways be established between certainnewly installed ports of cells in which the incomparable events occurand defining or re-defining TIPs at ports associated with said cells inmanners described in Section 6.6 of CHAPTER 3, it being possible to dosuch ad hoc coordination and synchronization also between any two groupsof non-intersecting incomparable events in A:implementation(), these adhoc synchronization and coordination methods being unique to TICC™-Ppde,not possible to implement in any other parallel programming paradigmwithout extensive revision of refinements, TICC™-Ppde providing methodsfor such ad hoc synchronization and coordination.
 6. Methods as recitedin claims 1, 2, 3, 4 or 5 further including following SMS methods todynamically build and analyze the causalnet while application isrunning, in parallel with the application: methods(6.1), for driving theSMS (Self-Monitoring System): statement (C.8) above providing the basisfor operation of SMS in TICC™-Ppde, agents embedded in pathways sendingsignals using CCPs (Causal Communication Primitives) to ports attachedto EventBuilder cells (eb cells) of SMS to automatically install messagedispatch and message delivery events in the growing causalnet ofA:implementation() while A:implementation() is running, as described inSection 7 of CHAPTER 3, each eb cell being connected to a pathwaythrough a distinct pair of ports in a port-vector attached to that ebcell, one port in the port-vector receiving signal from an agent in thepathway indicating message dispatch event occurring in the pathway, andthe other port in the port-vector receiving signal from another agent inthe pathway indicating the corresponding message delivery event in thesame pathway, as indicated in FIG. 19, on sensing signals delivered toboth ports in the said port-vector, the parent eb cell of theport-vector installing corresponding pairs of message dispatch anddelivery event instances in the growing causalnet, such updating of thecausalnet occurring while parent-cells C of ports C.p that received thedelivered message are executing C.p:tip(), time taken for installing thesaid event instances in the growing causalnet being one fiftieth to onehundredth the amount of time needed to execute C.p:tip(), each eb cellbeing capable of servicing about ten to fifteen pathways, allowing fordelays due to asynchronous executions in polling cycles of all cells,parallel updating of the growing causalnet by multiple eb cells beingpossible because each eb cell will be installing new communicationevents only in distinct non-intersecting branches of the causalnet,TICC™-Ppde providing tools to automatically coordinate parallelcomputations performed by eb cells and ea cells, eb-cells communicatingwith ea-cells by exchanging signals using CCPs; methods(6.2), foranalyzing events in a growing causalnet: EventAnalyzer cells (ea cells)in A:cells() automatically checking whether the growing causalnetsatisfies A:ALLEOPS(), eb cells signaling ea cells every time theyinstall new communication events in the causalnet, ea cells reporting anerror every time the structure in the growing causalnet ofA:implementation() violates the structure of A:ALLEOPS() by notsatisfying statement (C.7), reporting an impending error when specifiedupper bounds on timings of event occurrences are violated for someevents in the growing causalnet, or issuing alerts on identifyingoccurrences of a priori defined ALLEOPs event patterns in the growingcausalnet, one or more ea cells being dedicated to monitor the growingcausalnet for occurrences of a priori defined alert patterns, therebeing at least one ea cell for each eb cell in A:implementation(),A:cells() containing as many eb cells and ea cells as needed toguarantee operations in A:implementation() with no interference withtimings of events in A:implementation(), all eb cells and ea cellsoperating in parallel and in parallel with all other cells in A:cells(),with little or no interference with the operation of any cell inA:cells(), TICC™-Ppde providing tools to coordinate parallelcomputations performed by ea cells and eb cells by enabling eb cells andea cells to communicate with each other by exchanging signals usingCCPs; methods(6.3), for self-diagnosis and self-repair: SMS providingthe basis for eventually building self-diagnosis and self-repairfacilities in A:implementation(), ea cells identifying errors orimpending errors directly communicating with errant cells and usingvalidated CTL-assertions containing events associated with the errantcells to diagnose and repair the errant cells or dynamically replacingthem with new cells without interfering with normal operations in therest of A:TICC™-network(), ea cells identifying a priori defined alertpatterns responding to the identified alert patterns by dynamicallychanging parallel computations in a predetermined manner wherenecessary.
 7. Methods as recited in claims 1, 2, 3, 4, 5 or 6 furtherincluding the following twelve programming abstractions introduced byTICC-Ppde, enabling abstract design, implementation of the designthrough successive refinements, the programming abstractions enablingefficient running of arbitrarily scalable massively parallel computingsystems with automatic self-monitoring, the twelve abstractions being,Abstraction(7.1), Cells: cells being software abstractions of computingunits of parallel programming software systems, cells enabling abstractspecifications of parallel software system design, implementationthrough successive refinements, each cell running in a dedicated CPU(hardware ComPuting Unit), cells performing parallel computations byexchanging messages with each other, using their ports to send andreceive messages via communication pathways interconnecting ports ofcells, the graph of cells interconnected by pathways in application Abeing called A:TICC™-network(), cells being totally self-contained, notusing an Operating System to assist their operations, TIC™-Ppdeproviding tools enabling cells to perform all computations needed tobuild A:TICC™-network(), invoke and execute pthreads toprocess/construct messages they exchange with each other, invoke andexecute protocols to send/deliver messages, and suspend/resume theiroperations on receipt of interrupt messages, with no assistance from anysoftware not defined in the cell itself or software components attachedto or tuned to the cell; Abstraction(7.2), Pathways: pathways beingabstractions of communication channels, there being two kinds ofpathways, sm-pathways and dm-pathways, sm-pathways interconnecting portsof cells running in an SMP (Shared-Memory multiprocessor), dm-pathwaysinterconnecting ports of cells running in a DMP (Distributed-Memorymultiprocessor), the computing nodes of the DMP being SMPs, each port inSMP, called the parent-cell of the port, each cell having multiple portsattached to it, each port of a cell being connected to only one uniquepathway, multiple ports attached to distinct cells being connected tothe same pathway, thereby enabling group-to-group communications,pathways containing agents and virtualMemories embedded in them, thesame agent or virtualMemory never being embedded in more than onepathway, agents performing routing, synchronization and coordination ofmessage traffic over the pathway in which they are embedded, agents alsosending signals to SMS (Self-Monitoring System) to install messagedispatch and message delivery events that occur in pathways they areembedded in, for any pathway, P, P:ports() being the set of portsconnected to P, P:agents() and P:virtualMemories() being the sets ofagents and virtualMemories embedded in P, the union of the three setsP:ports(), P:agents() and P:virtualMemories() being the pathwaycomponents of pathway P, no two distinct pathways ever having anypathway component in common, thereby pathways enabling simultaneousparallel message exchanges in A:TICC™-network() without messageinterference, TICC™-Ppde providing tools to dynamically install cellsand pathways in A:TICC™-network() while application A is running;Abstraction(7.3), VirtualMemories: software abstractions calledvirtualMemories being declared when pathways are installed, realhardware memory areas, or memory modules, being assigned tovirtualMemories at compile time or run time of an application, eachsm-pathway, S, having only one unique virtualMemory, S.vM, embedded init, all ports p_(i) connected to any sm-pathway residing in the same SMP(Shared-memory Multi-Processor), all ports p_(i) connected to anysm-pathway S having the same virtualMemory, p_(i).vM=S.vM associatedwith them, each dm-pathway, D, interconnecting port-groups, pG[j],residing in different and distinct SMPs, SMP[j], (Shared-Memorymulti-Processor j) in a DMP (Distributed-Memory multi-Processor), eachdm-pathway D having more than one virtualMemory embedded in it, onevirtualMemory, pG[j].vM being tuned to port-group pG[j] in each SMP[j],pG[j].vM being identical to q_(j).vM for all q_(j) in pG[j],virtualMemories p_(i).vM and q_(j).vM, holding messages transported viasaid pathways, said virtualMemories also holding pthreads and methodsused by parent-cells of ports p_(i) and q_(j), respectively, to processand create messages, in addition the said virtualMemories holdingprotocols, p_(i).protocol and q_(j).protocol, to transport messages overthe pathways S and D, respectively, virtualMemories and pathwaysproviding execution environments for all pthreads, methods and protocolsthey hold, virtualMemory organization contributing to data securityprivacy and integrity isolation of parallel computations performed bycells, efficient execution of parallel programs and simplification ofshared-memory multi-processor designs for multi-core chips;Abstraction(7.4), Protocols: each port p connected to each pathwayhaving a protocol, p.protocol, defined for it, only the parent-cell of pbeing allowed to execute p.protocol, execution of p.protocol byparent-cell of port p causing signals to be exchanged by pathwaycomponents, the signals exchanged by pathway components traveling overthe pathway ultimately establishing a context in which message in p.vMis delivered to its intended recipients in sm-pathways or transported toits intended recipients via hardware signal transmission lines indm-pathways, hardware agents embedded in dm-pathways also participatingin protocol executions to transmit, coordinate, synchronize and routemessages over dm-pathways said agents being embedded in, protocolsenabling multiple simultaneous parallel message exchanges in anapplication limited only by the number of pathways in the application;Abstraction(7.5), CCPs (Causal Communication Primitives): CCPs beingused to programmatically exchange signals between components in apathway, each CCP being a statement in TICC™-Ppde programming languagehaving the form X:x→Y, X,Y being components embedded in a pathway, xbeing a signal transmitted by the CCP from X to Y, signals sent/receivedby components X,Y controlling the states of ndFSMs (non-deterministicFinite State Machines) embedded in X,Y, CCP being implemented either insoftware or in hardware, hardware CCP being implemented as a machineinstruction in a CPU, each protocol being defined by concatenations ofCCPs, such concatenations having the form X:x₁→Y:x₂→Z, X,Y,Z being allcomponents in the same pathway, CCPs appearing in protocols being attimes embedded in other programming statements of TICC™-Ppde, softwareCCP taking only about 25 to 50 nanoseconds to execute in a 2-gigahertzCPU, hardware CCP taking only about 5 nanoseconds to execute in a2-gigahertz CPU, CCPs being the central and most important abstractionintroduced by TICC™-Ppde, CCPs being solely responsible for makingpossible the parallel program organization in TICC™-Ppde;Abstraction(7.6), Tuning and Attachments: all components of any pathwayP exchanging signals, being always tuned to each other, tuning enablingeach such component to be always ready to receive and respondimmediately to signals they receive from other components of thepathway, thereby enabling guaranteed high-speed message exchanges viapathway P with latencies in the range of at most a few hundrednanoseconds with 2-gigahertz CPUs, tuning being a reflexive symmetricrelation, any cell, C, being able to execute only methods or pthreadsdefined in C, or components embedded in any pathway connected to anyport attached to C, C using only data defined in components attached Cor data defined in components of said pathways, attachment being areflexive, symmetric, transitive relation, tuning and attachmentcontributing to the modular object oriented organization of parallelsoftware systems in TICC™-Ppde; Abstraction(7.7), Ports: port is asoftware abstraction, each port p being attached to its uniqueparent-cell, port p having a unique virtualMemory, p.vM, associated withit, parent-cell of port p using p to send messages in p.vM to othercells via p.pathway connected to p and receive messages from other cellsvia the same p.pathway, each port p protecting data and methods in p.vM,by giving access to said data and methods only to its parent-cell andonly when the parent-cell is ready to use those data and methods,terminating access after such use is completed, each port p havingembedded in it a non-deterministic Finite state machine p.ndFsm with 2states S (send) and R (receive), the states being used to coordinatemessage sending/receiving operations performed by the parent-cell of p,the states also being used to control access to virtualMemory p.vM byparent-cell of p, p.state=p.ndFsm.state, coordination and access controlmethods being described in FIGS. 1 through 4 of Section 1 of CHAPTER 3,parent-cell of p having access the virtualMemory p.vM to send messageout via port p only when the state of p.state=S, port p receivingmessages only when the state of p.state=R, ports in dm-pathwayscontaining ndFsms having 4 states, S, S′, R, R′, two message sendingstate S and S′, and two message receiving states R and R′, ports notonly sending and receiving messages but also controlling access tovirtualMemories and thus protecting data and methods in virtualMemories,in addition making possible distributed organization of hardwareShared-Memory Modules, SMMs, which are dynamically assigned tovirtualMemories and are used by CPUs as and when needed;Abstraction(7.8), Agents: agents in sm-pathways being softwareabstractions, agents being embedded in pathways, each agent, a,containing a 2-state ndFsm, a.ndFsm, embedded in it with states S (send)and R (receive), a.state=a.ndFsm.state, agents using their states toroute, synchronize and coordinate message transmissions over pathwaysthey are embedded in, as described in Section 1 of CHAPTER 3, FIGS. 2through 4 and Section 7 of Chapter 3, agents also signaling componentsof SMS to dynamically install in the causalnet of a running application,message dispatch and message delivery events that occur in the pathwayssaid agents are embedded in, as described in Section 7 of CHAPTER 3,dm-pathways containing hardware agents with 4 states, S, S′, R, R′,agents automatically synchronizing and coordinating all communicationsenforcing security and driving the self-monitoring system and thusslaving a unique and central role in TICC™-Ppde; Abstraction(7.9), TIPs(Thread Interaction Primitives): TIPs being software abstractions thatspecify how the parent-cell of a port p in application A receives andresponds to a message delivered to p, or how parent-cell checksreadiness of a port p to send out a message, constructs message andsends it out via the port, every port attached to every cell inapplication A having a TIP defined for it, some TIPs being embedded inother TIPs, the set of all TIPs defined at the ports of a cell beingused by that cell to perform parallel computations in application A,there being ten kinds of TIPs needed to specify all of parallelcomputations, 5 synchronous and 5 asynchronous, TIPs providing a compactmodular specifications of interactions among cells, that can get ascomplicated as any computation can get the modular characterization ofinteractions provided by TIPs facilitating formal verification andvalidation of implementations of applications and cell isolation;Abstraction(7.10), CIPs (Cell Interaction Protocols): CIPs beingsoftware abstractions that specify how a cell initializes itself, pollsits ports, processes messages delivered to its ports and responds tothem, or creates new messages and sends them out via one or more of itsports, CIPs providing the basic processes that makes all parallelcomputations in TICC™-Ppde possible; Abstraction(7.11),A:TICC™-network(): A:TICC™-network() being a software abstraction of thecontrol structure of the parallel computations in application A,A:TICC™-network() implicitly specifying synchronization and coordinationof all computational and communication activities that occur during theparallel computations, just as the same sequential program may be run indifferent data structure definitions if the sequential program and datastructure definitions are properly defined the same set of pthreads,A:pthreads() of an application A may be run in differentA:TICC™-network()s, if initialization routines in CIPs (Cell InteractionProtocols) are properly defined thereby enabling program optimizationthrough chances in execution control structure; Abstraction(7.12), TheSelf Monitoring System, SMS: SMS being an abstraction that is unique toTICC™-Ppde, SMS being a software abstraction of mechanisms used inTICC™-Ppde to monitor the performance of a running application A, whileit is running, in parallel with the application with no interferencewith timings of events occurring in the application, in order to detectand report errors in performance, pending errors and occurrences of apriori defined patterns of events while the application A is running,SMS using cell abstractions called eb cells (event builder cells) and eacells (event analyzer cells) to build and constantly monitor the growingcausalnet of a running application, SMS being a feature that is uniqueto TICC™-Ppde.
 8. Methods and abstractions as recited in claims 1, 2, 3,4, 5, 6 or 7 further including five verification-abstractions introducedin TICC-Ppde, the verification-abstractions enabling TICC™-Ppde toformally validate parallel programs and run them with automaticself-monitoring, the five verification methods and abstractions being,Abstraction(8.1), Event Classes: event classes being abstractions ofcomputational and communication events occurring while an application Ais running, each event class being a pair (name, t), there being twokinds of event classes, action event classes and communication eventclasses, name in an action event class denoting a statement inTICC™-Programming language, or denoting a pthread, or denoting acondition in the parallel programs implementing application A, name incommunication event classes having one of the forms, p^(S), p^(F), orp^(D) where p is the name of a port in application A, the superscript Ssignifying, the port p is sending out a message, superscript Fsignifying, port p is forwarding a message, and superscript Dsignifying, a message is being delivered to port p, t representing asequence of time points at which event instances of the event class mayoccur in a run of application A, t being called the time-map of thenamed event class; Abstraction(8.2), ALLowed Event Occurrence Patterns,ALLEOPs: ALLEOPs representing abstractions of computationaldependencies, said dependencies being expressed through a binary,irreflexive, asymmetric and transitive causal relation between eventclasses, ALLEOPs being the network of event classes connected to eachother by conditional or unconditional directed arrows representingcausal relations between pairs of event classes, a causal chain being asequence of events connected by directed arrows (causal relations), thenetwork of causal chains of event classes capturing patterns ofcomputational event instances occurring in parallel programs forapplication A while application A is running, p:port-ALLEOP() being theset of all causal chains of event classes occurring in p:TIP(),C:cell-ALLEOP() being the set of all causal chains of event classesoccurring in C:CIP(), A:ALLEOPS() being the set of all causal chains ofevent classes occurring in application A; Abstraction(8.3), EventInstances and Traces: events, (name, t_(i)) for i=1, 2 . . . , n . . .being instances of the event class, (name, t), occurring at timeinstances t=[t₁, t₂, . . . , t_(n), . . . ], n≧0, while an applicationis running, there being no instance of event class (name, t) when n=0,pairs of event instances X(t_(i)) and Y(t_(j)) of respective eventclasses (X, t_(x)) and (Y, t_(y)) being connected to each other by aconditional or unconditional directed arrow representing causal relationonly if its corresponding event classes are connected by such an arrowin ALLEOPs, the set of all possible causal chains of event instancesoccurring in any run of application A being called A:TRACES(),A:TRACES() being derived automatically from A:ALLEOPS(), arepresentation of the set of all possible A:TRACES() in application Abeing called A:domain(), p:port-trace(t_(P)) being the traceautomatically derived from p:port-ALLEOP(), C:cell-trace(t_(C)) beingthe trace automatically derived from C:cell-ALLEOP(); Abstraction(8.4),ECT-networks: p:port-ECT(t_(P)) being the Event Characterization Networkconsisting of ECT-blocks, representing causal chains of all eventinstances occurring in p:port-trace(t_(P)) organized in a tabular form,port-ECTs being interconnected in a manner consistent withA:TICC™-network() and A:ALLEOPS(), such ECT-networks facilitating formalinteractive proof generation by TICC™-Ppde, C:cell-ECT(t_(C)) being theECT-network corresponding to C:cell-trace(t_(C)), A:ECT-network() beingthe ECT-network corresponding to A:TRACES(); Abstraction(8.5),Causalnets: p:port-causalnet(t_(P)) being an abstraction ofp:port-trace(t_(P)) containing only causal chains of communication eventinstances occurring in p:port-trace(t_(P)), C:cell-causalnet(t_(C))being an abstraction of C:cell-trace(t_(C)) containing only causalchains of communication event instances in C:cell-trace(t_(C)),A:causalnet() being an abstraction of A:TRACES() containing only causalchains of communication event instances in A:TRACES(), the SMS(Self-Monitoring System) generating automatically the causalnet ofapplication A while it is running, in parallel with the run,automatically monitoring the dynamically growing causalnet to identifyand report errors, pending errors and occurrences of a priori definedpatterns of event instances.
 9. Methods and abstractions as recited inclaims 1, 2, 3, 4, 5, 6, 7, or further including following method toprovide an integrated environment for design, development, verificationand running with self-monitoring of applications, A: TICC™-Ppde itselfperforming CPU assignments to cells, cell activations in CPUs assignedto them, parallel process management, pthread management,communications, interrupt management, security enforcement,synchronization and coordination, without having to invoke an operatingsystem or any other external software to perform any part of theseservice, TICC™-Ppde using operating system in the current prototypeimplementations only for memory management, cache management and accessto secondary storage devices and internet, it being possible toimplement all of these services in TICC™-Ppde itself with all neededoperating system services being provided in parallel, thereby providingan environment for integrated design, development, verification andrunning of parallel software systems with self-monitoring.
 10. Methodsand abstractions as recited in claims 1, 2, 3, 4, 5, 6, 7, 8 or 9further including following method to design, implement and run parallelprogramming applications, A: any parallel computer program for anyapplication A using any or all of the methods and abstractions recitedin claim 1 through claim 9, using programmatic signal exchanges toorganize and control parallel software systems, implemented in hardwareor software, with or without formal validation and self-monitoring, orwith only partial formal validation and partial self-monitoring.